Check for async-signal-unsafe functions

[Markus Elfring]

A ​signal handler implementation must adhere to strict requirements.

• The ​list of functions that may be called is limited.
• A recommended data type for access to global variables is ​sig_atomic_t.

Would you like to add a search capability for the property "async-signal-safety" in the source files if the rules were broken?

[amai]

That might be useful, though quite difficult to implement in cppcheck:

1. The signal handler has to be registered in the same source than the handler is implemented /defined - so cppcheck can analyze
2. The list of system functions to be called is white-listed if I understand the referenced specification - making it hard to detect the invalid ones.
3. cppcheck might not know about user code functions to be called from the signal handler

[amai]

Replying to amai:

That might be useful, though quite difficult to implement in cppcheck:

1. The signal handler has to be registered in the same source than the handler is implemented /defined - so cppcheck can analyze

Ok, that requirement got removed recently. The whitelist is available within the given external resource.

[kidkat]

FYI clang-tidy has the bugprone-signal-handler check nowadays and is soon landing some major improvements to it.

See
​https://clang.llvm.org/extra/clang-tidy/checks/bugprone/signal-handler.html
​https://reviews.llvm.org/D118996

[Kamil Dudka]

The GCC analyzer also checks for this programming mistake: ​https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Static-Analyzer-Options.html#index-Wno-analyzer-unsafe-call-within-signal-handler