Use of <signal.h> in Objective-C code
ID |
objectivec.correctness.avoid_signal |
Severity |
info |
Remediation Complexity |
hard |
Remediation Risk |
high |
Remediation Effort |
medium |
Resource |
Control Flow |
Language |
Objective-C |
Description
Reports an include of <signal.h> or a call to its signal-handling functions - signal, raise, sigaction, sigprocmask, sigsuspend, sigwait.
Rationale
A signal handler runs asynchronously, on an arbitrary thread, at an arbitrary point in the program. Only async-signal-safe functions may be called from it, which rules out almost the whole Objective-C runtime: allocating an object, taking a lock, autoreleasing, and logging are all unsafe and can deadlock or corrupt state when they interrupt themselves. The behaviour of a handler that touches anything else is implementation-defined, so the same code can work in testing and hang in production.
The following code illustrates the pattern detected by this rule:
// FLAGGED: Use of <signal.h> in Objective-C code
#include <signal.h>
#import <Foundation/Foundation.h>Remediation
Prefer the Cocoa and libdispatch equivalents, which deliver the event on a queue you control and impose no async-signal-safety restriction - dispatch_source_create with DISPATCH_SOURCE_TYPE_SIGNAL for signals you must observe, NSNotificationCenter or a delegate callback for application lifecycle events, and an ordinary error return for failures. If a handler is unavoidable, restrict its body to setting a volatile sig_atomic_t flag.