Page History

The C++ Standard, [support.runtime] paragraph 10, paragraph 10 [ISO/IEC 14882-2014], states:

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 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 passed to f, atomic_is_lock_free(A) yields  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.²²⁸

Footnote 228 states:

In particular, a signal handler using exception handling is very likely to have problems. Also, invoking std::exit may  may cause destruction of objects, including those of the standard library implementation, which, in general, yields undefined behavior in a signal handler (see 1.9).

If your signal handler is not a POFplain old function, then the behavior of calling it a call to it in response to a signal is implementation-defined at best, and likely to result in undefined behavior at worst.. All signal handlers must meet the definition of a plain old function. In particular, this prohibits use of features that exist in C++ but not C (such as non-POD objects and exceptions), including indirect use of such features through function calls, in addition to the restrictions placed on signal handlers in a C program. See 11. Signals (SIG) for rules regarding conforming use of signals in a C program.

Noncompliant Code Example

In this noncompliant code example, the signal handler is declared as a static function. However, since all signal handler functions must have C language linkage, and C++ is the default language linkage for functions in C++, calling the signal handler results in undefined behavior.

#include <csignal>
 
static void sig_handler(int sig) {
  // Implementation details elided.
}

void f() {
  if (SIG_ERR == std::signal(SIGTERM, sig_handler)) {
    // Handle error
  }
}

Compliant Solution

This compliant solution defines sig_handler() as having C language linkage. Note that this requires all signal handler functions to be declared with external linkage instead of internal linkage.

#include <csignal>
 
extern "C" void sig_handler(int sig) {
  // Implementation details elided.
}

void f() {
  if (SIG_ERR == std::signal(SIGTERM, sig_handler)) {
    // Handle error
  }
}

Noncompliant Code Example

In this noncompliant code example, a signal handler calls a function which allows exceptions, and attempts to handle any exceptions thrown. Since exceptions are not part of the common subset of C and C++ features, this results in implementation-defined behavior. However, it is unlikely that the implementation's behavior will be suitable. For instance, on a stack-based architecture where a signal is generated asynchronously (instead of as a result of a call to std:abort() or std::raise()), it is possible that the stack frame is not properly initialized, causing stack tracing to be unreliable, and preventing the exception from being caught properly.

#include <csignal>

static void g() noexcept(false);

extern "C" void sig_handler(int sig) {
  try {
    g();
  } catch (...) {
    // Handle error
  }
}
 
void f() {
  if (SIG_ERR == std::signal(SIGTERM, sig_handler)) {
    // Handle error
  }
}

Compliant Solution

There is no compliant solution where g() can be called because it allows exceptions. Even if g() were implemented such that it handled all exceptions and was marked noexcept(true), it would still be noncompliant to call it from a signal handler because g() would still use a feature that is not a part of the common subset of C and C++ features allowed by a signal handler. Therefore, this compliant solution removes the call to g():

#include <csignal>

static void g() noexcept(false); // Not called

extern "C" void sig_handler(int sig) {
  // Implement g()'s behavior as best as possible given the
  // constraints placed on a signal handler function.
}

void f() {
  if (SIG_ERR == std::signal(SIGTERM, sig_handler)) {
    // Handle error
  }
}

Risk Assessment

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, failure to comply with this rule can have benign consequences, abnormal program termination, or possibly even arbitrary code execution.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

Image Added Image Added Image Added