Page properties | ||
---|---|---|
| ||
C++17 is likely to change this around considerably. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0270r1.html for details. |
The C++14 Standard, [support.runtime], paragraph 10 [ISO/IEC 14882-2014], states the following:
The common subset of the C and C++ languages consists of all declarations, definitions, and expressions that may appear in a well-formed C++ program and also in a conforming C program. A POF (“plain old function”) is a function that uses only features from this common subset, and that does not directly or indirectly use any function that is not a POF, except that it may use plain lock-free atomic operations. A plain lock-free atomic operation is an invocation of a function f from Clause 29, such that f is not a member function, and either f is the function atomic_is_lock_free, or for every atomic argument A passed to f, atomic_is_lock_free(A) yields true. All signal handlers shall have C linkage. The behavior of any function other than a POF used as a signal handler in a C++ program is implementation-defined.228
Footnote 228 states the following:
...
If your signal handler is not a plain old function, then the behavior of a call to it in response to a signal is implementation-defined, at best, and is likely to result in undefined behavior. All signal handlers must meet the definition of a plain old function. In addition to the restrictions placed on signal handlers in a C program, this definition also prohibits the use of features that exist in C++ but not in C (such as non-POD [non–plain old data] objects and exceptions). This includes indirect use of such features through function calls.
In C++17, the wording has changed and relaxed some of the constraints on signal handlers. Section [support.signal], paragraph 3 says:
An evaluation is signal-safe unless it includes one of the following:
— a call to any standard library function, except for plain lock-free atomic operations and functions explicitly identified as signal-safe. [ Note: This implicitly excludes the use of new and delete expressions that rely on a library-provided memory allocator. — end note ]
— an access to an object with thread storage duration;
— a dynamic_cast expression;
— throwing of an exception;
— control entering a try-block or function-try-block;
— initialization of a variable with static storage duration requiring dynamic initialization (6.6.3, 9.7)220; or
— waiting for the completion of the initialization of a variable with static storage duration (9.7).A signal handler invocation has undefined behavior if it includes an evaluation that is not signal-safe.
Signal handlers in code that will be executed on C++17-compliant platforms must be signal-safe.
Noncompliant Code Example
...
Failing to use a plain old function as a signal handler can result in implementation-defined behavior as well as undefined behavior. Given the number of features that exist in C++ that do not also exist in C, the consequences that arise from failure to comply with this rule can range from benign (harmless) behavior to abnormal program termination, or even arbitrary code execution.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MSC54-CPP | High | Probable | High | P6 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Helix QAC |
| C++2888 | |||||||
Klocwork |
| CERT.MSC.SIG_HANDLER.POF | |||||||
Parasoft C/C++test |
|
|
|
CERT_CPP- |
MSC54-a | Properly define signal handlers | ||||||||
Polyspace Bug Finder |
| Checks for unsafe signal handlers (rule fully covered) |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
SEI CERT C Coding Standard | SIG30-C. Call only asynchronous-safe functions within signal handlers SIG31-C. Do not access shared objects in signal handlers |
Bibliography
[ISO/IEC 14882-2014] | Subclause 18.10, "Other Runtime Support" |
...
...