Jonathan Andrews <jon@xxxxxxxxxxxxxxx> writes: > Would it be possible to add a warning to gcc C when code in an signal > handler (alarm) uses non thread safe calls. It would be fairly hard to do this in a useful way. A signal handler could call a function defined in some other file. If the compiler can't see that function, it would not be able to warn about that function or any functions that it might call. So the best we could do is warn about system functions that are known to be non-async-signal-safe. Even that set is hard to determine. There are some functions that older versions of the POSIX standard considered to be async-signal-safe that newer versions do not consider to be safe. And standards aside, the exact set depends on your operating system, and in fact on the exact version of your operating system. > Gcc's own documentation is incomplete on the subject Well, it's not really a compiler issue. > The example here risks not just printing incorrect values but stopping > completely waiting in a futex forever. > http://www.gnu.org/software/libc/manual/html_node/Non_002datomic-Example.html#Non_002datomic-Example > > No warning here > http://www.gnu.org/software/libc/manual/html_node/Setting-an-Alarm.html Here you are talking about glibc, which is a different project maintained by different people. > http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04 > > "unspecified" is a very vague warning. Its sometimes acceptable for > something to give the wrong answer for its output but its never > acceptable for a process to stall and never resume. If this kind of > thing is the outcome then gcc needs to babysit me more :-) Calling a non-async-signal-safe function is not "unspecified," it is "undefined." In a standard, "undefined" is a term of art: it means that absolutely anything can happen, which certainly includes having the program stop and never resume. Your request for a warning is reasonable, I just don't see a way to implement it such that it is useful. Ian
