Detect calls to functions that are not `signal-safe` in signal handlers

[michael-schwarz]

For reviewing #1965, I read some documentation on signal handlers. There is in particular this rule

An async-signal-safe function is one that can be safely called from within a signal handler. Many functions are not async-signal-safe. In particular, nonreentrant functions are generally unsafe to call from a signal handler.

https://man7.org/linux/man-pages/man7/signal-safety.7.html

and a list of such async-signal-safe functions.

We may want to add an analysis that tracks whether the current thread is a signal handler, and warn whenever a library function that is not async-signal-safe is called.

May be a good BSc project.

[sim642]

I happened to look at the signals part of the C standard and it's actually extremely strict in this regard:

If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if [...] the signal handler calls any function in the standard library other than

• the abort function,
• the _Exit function,
• the quick_exit function,
• the functions in <stdatomic.h> (except where explicitly stated otherwise) when the atomic arguments are lock-free,
• the atomic_is_lock_free function with any atomic argument, or
• the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler. Furthermore, if such a call to the signal function results in a SIG_ERR return, the object designated by errno has an indeterminate representation.

By that definition, it's easier to mark those few functions which are signal-safe, rather than everything else.

But I suppose different users might care about different strictness of signal-safety, whether it's the C standard one or the one declared by glibc implementation. Maybe it's useful to even have separate attributes to follow depending on an option.