Page History

According to Section 7.14.1.1 of the C Rationale \[[ISO/IEC 03|AA. C References#ISO/IEC 03]\]:

Similarly, Section 7.14.1 paragraph 5 of C99 \[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] states that if the signal occurs other than as the result of calling the {{abort}} or {{raise}} function, the behavior is [undefined|BB. Definitions#undefined behavior] if

The second problem is that the {{free()}} function is also not \[[asynchronous-safe|AA. C References#asynchronous-safe]\], and its invocation from within a signal handler is also a violation of this rule. If an interrupt signal is received during the {{free()}} call in {{main()}}, the heap may be corrupted.

The following table from the the Open Group Base Specifications \[[Open Group 04|AA. C References#Open Group 04]\], defines a set of functions that are asynchronous—signal-safe. Applications may invoke these functions, without restriction, from signal handler.

For an overview of software vulnerabilities resulting from improper signal handling, see Zalewski's paper on understanding, exploiting, and preventing signal-handling-related vulnerabilities \[[Zalewski 01|AA. C References#Zalewski 01]\]. [VU #834865|http://www.kb.cert.org/vuls/id/834865] describes a vulnerability resulting from a violation of this rule.

\[[Dowd 06|AA. C References#Dowd 06]\] Chapter 13, "Synchronization and State"
\[[ISO/IEC 03|AA. C References#ISO/IEC 03]\] Section 5.2.3, "Signals and interrupts"
\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.14, "Signal handling {{<signal.h>}}"
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 479|http://cwe.mitre.org/data/definitions/479.html], "Unsafe Function Call from a Signal Handler"
\[[Open Group 04|AA. C References#Open Group 04]\] [longjmp|http://www.opengroup.org/onlinepubs/000095399/functions/longjmp.html]
\[[OpenBSD|AA. C References#OpenBSD]\] [{{signal()}} Man Page|http://www.openbsd.org/cgi-bin/man.cgi?query=signal]
\[[Zalewski 01|AA. C References#Zalewski 01]\]