Rule 11. Signals (SIG)

Robert and I discussed adding a recommendation here to replace ALL default handlers when working with crypto.  The default handlers call abort which forces a coredump, now all of your plaintext is sitting on the hard drive and all because you got a SIGALRM or somesuch

According to DCL05-A, the specification of the signal function could probably be written more clearly using typedef void (*sighandler_t)(int) for the type of the second parameter and return value.

signal() is so problematic that mention should be made up front of POSIX sigaction/sigvec.  The best policy is to not use signals for IPC, only (at most) to field a manual interrupt (SIGINT) and set a flag that can be tested in the main control loop.

It should be mentioned somewhere that if one is using assert(), it would be wise to catch SIGABRT and do something like call exit(EXIT_FAILURE) so that the atexit-registered handlers are not bypassed.

Often enough people just don't believe the Standard about how limited signal handers are.  So I think you should rearrange the signal handing section a bit and change emphasis.  Something like this:

Let the quote from the Standard about what signal handlers can do, be the first rule or recommendation, amended by the point you added that the C Committee agreed they can read volatile sig_atomic_t, and they can use async-safe functions.

"Yes, safe standard C signal handlers really are that limited.  The C standard doesn't say that just to be difficult, but because that was all vendors could agree they'd all implement. If you want a handler to do more safely, you need OS extensions."

 ([Edited comment, had dropped some parts]  Plus I imagine there may be special cases which were just hard or pointless to list.  in particular since people will want to do more in signal handers anyway, and signal handlers may be a desperation measure.  E.g. I doubt I'll ever meet a computer where it's unsafe to read a const static-storage variable short of in debugging environments like valgrind, but maybe someone should tell me to read my previous paragraph.  Not sure what, if anything, to say about that.  But signal handlers in particular may be set up just to say something sensible before crashing, in which case it may be acceptable if reality breaks expectaions.  Is there a general exception to the rules in this standard which allows "I know this may break, but it's best to do it anyway"-kind of code?)

(Edit again: Took me all of 3 minutes to think of an example of my "doubt" I may already have met.  make a

 struct { const char x; char y; }

on a machine without atomic char writes, only atomic word writes. Or where the compiler prefers word writes. x gets written when updating y. Maybe the compiler would be allowed to do that in strange ways between sequence points, if it should find it useful.  I'm too tired to think straight now, but I at least proved my point about not believing

anyway, continuing with my suggested text:

 "E.g. it may be unsafe to update an int - that may not be an atomic operation.  This is why the sig_atomic_t type is needed. Even if an int can be accessed atomically, the compiler might not always choose that way to access it.

Adding volatile need not help - that ensures modifications are complete at sequence points, but signals do not have the courtesy of arriving at sequence points.

If a function is thread-safe, that's not merely insufficient to let a signal handler call it, it may make it worse.  The function may be thread-safe because it locks a resource before accessing it.  If a thread is signalled while it is currently using that resource and thus holds the lock, the thread can freeze - it sits down to wait for itself to free the lock.  This means, among other things, that printing to stderr in a signal handler can deadlock the program.  Use an async-safe OS function instead, like write() on Posix."