Calling the signal() function in a multithreaded program is undefined behavior (see undefined behavior 135).
This noncompliant code example invokes the signal() function from a multithreaded program:
| #include <signal.h>
#include <threads.h>
 
volatile sig_atomic_t flag = 0;
void handler(int signum) {
  flag = 1;
}
/* Runs until user sends SIGUSR1 */
int func(void *data) {
  while (!flag) {
    /* ... */
  }
  return 0;
}
int main(void) {
  signal(SIGUSR1, handler); /* Undefined behavior */
  thrd_t tid;
  
  if (thrd_success != thrd_create(&tid, func, NULL)) {
    /* Handle error */
  }
  /* ... */
  return 0;
} | 
NOTE: The SIGUSR1 signal value is not defined in the C Standard; consequently, this is not a C-compliant code example.
This compliant solution uses an object of type atomic_flag to indicate when the child thread should terminate its loop:
| #include <stdatomic.h>
#include <threads.h>
 
atomic_flag flag = ATOMIC_VAR_INIT(0);
int func(void *data) {
  while (!flag) {
    /* ... */
  }
  return 0;
}
int main(void) {
  int result;
  thrd_t tid;
  
  if (thrd_success != thrd_create(&tid, func, NULL)) {
    /* Handle error */
  }
  /* ... */
  /* Set flag when done */
  while (!atomic_flag_test_and_set(&flag))
    ; /* Continue attempts */
  return 0;
} | 
CON37-EX1: Implementations such as POSIX that provide defined behavior when multithreaded programs use custom signal handlers are exempt from this rule [IEEE Std 1003.1-2013].
Mixing signals and threads causes undefined behavior.
| Rule | Severity | Likelihood | Remediation Cost | Priority | Level | 
|---|---|---|---|---|---|
| CON37-C | Low | Probable | Low | P6 | L2 | 
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
| Tool | Version | Checker | Description | 
|---|---|---|---|
| CodeSonar | BADFUNC.SIGNAL | Use of signal | |
| Parasoft C/C++test | 9.5 | MISRA2012-RULE-21_5_b | Use of signal | 
| [IEEE Std 1003.1-2013] | XSH 2.9.1, "Thread Safety" |