Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: I'm trying to get the POSIX stuff out of the general text areas and into the POSIX specific areas. Also made some additional edits.

...

This rule is a special case of SIG31-C. Do not access or modify shared objects in signal handlers. The object designated by errno is of static storage duration and is not a volatile sig_atomic_t.  As a result, performing any action that would require errno to be set would normally cause undefined behavior.  The C standard makes a special exception for errno in this case, saying the only thing that is allowed to go wrong is that errno takes on an indeterminate value.  This makes it possible to call signal() from within a signal handler without risking completely unrestricted undefined behavior, but the handler, and any code executed after the handler returns, must not depend on the value of errno being meaningful.

POSIX is less restrictive than C99 about what applications can do in signal handlers. It has a long list of async-signal-safe functions that can be called. Many of these functions set errno on error. This can lead to a situation where a signal handler is executed in between a call to a failed function and the subsequent inspection of errno, and thus the value inspected is not the one set by that function but the one set by a function call in the signal handler. POSIX applications can avoid this problem by ensuring that signal handlers which contain code that might alter errno always save the value of errno on entry and restore it before returning.

Non-Compliant Code Example

...

Non-Compliant Code Example (POSIX)

POSIX is less restrictive than C99 about what applications can do in signal handlers. It has a long list of asynchronous-safe functions that can be called. Many of these functions set errno on error. This can lead to a situation where a signal handler is executed in between a call to a failed function and the subsequent inspection of errno, and consequently the value inspected is not the one set by that function but the one set by a function call in the signal handler. POSIX applications can avoid this problem by ensuring that signal handlers which contain code that might alter errno always save the value of errno on entry and restore it before returning.

The signal handler in this non-compliant code example alters the value of errno, and therefore resultantly, could cause incorrect error handling if executed in between a failed function call and the subsequent inspection of errno.

...