> The setjmp(3) in main.c which is used when ctrl-c is catched (SIGINT)
> is kept which is legitim IMO for that use and done this way by a lot
> of command line programs (ftp, ed, restore etc.) to return to the
> command prompt no matter which routine was active (e.g. blocking
> fgets(3)).

Well, just because lots of programs use that method does not make it
legitimate, because in the end I must say this: IT IS STILL NOT SAFE.

Think about it.

When that ^C comes in, is it not possible that our code is currently running
inside malloc()? Just picking an example here, but what about stdio? Or
who knows what else?

So then the signal comes in, and we longjmp back into main, and now what?

Now your malloc heap is unsafe. Or stdio is in an inconsistant state.
Or who knows what else.

And now the code WILL crash later on. And there is no solution to
this besides adding signal blocking stubs all through the code, for
everytime you wish to do something which might conceiveably not be
re-entrant.

So while it might be what a lot of programs do, my point is that it
is 100% unsafe -- in all cases -- to ever use setjmp. Well, I have
actually used it safely in one program before, but the costs are very
high because you really must do signal blocks around just about any
sequence of code which calls a function which is NOT LISTED in signal.h

This is what I call a reverse signal race.