On async-signal safety.

Author: janpgit

signals.tex

@@ -386,7 +386,8 @@
 \end{minipage}
 \begin{itemize}
 \item assigns an action \emph{\texttt{act}} for a signal \emph{\texttt{sig}},
-previous setting is returned in \emph{\texttt{oact}}, if non-zero
+previous setting is returned in \emph{\texttt{*oact}}, if \emph{\texttt{oact}}
+is non-zero
 \item structure \texttt{sigaction} contains:
     \begin{itemize}
 ifdef([[[NOSPELLCHECK]]], [[[
@@ -430,8 +431,9 @@
 is listed in SUSv4 in section \emph{System Interfaces: General Information
 $\Rightarrow$ Signal Concepts $\Rightarrow$ Signal Actions (2.4.3)}.  Systems
 can extend the list, of course.  Whether a function is safe to use in a signal
-handler or not should be documented in its manual page.  On Linux, see also
-the \texttt{signal-safety(7)} manual page.
+handler or not should be documented in its manual page.  On Linux, see
+the \texttt{signal-safety(7)} manual page and also check what it says about
+\texttt{printf}.
 \item Using static data and/or locking in a function would generally be a
 problem for its asynchronous signal safety.  It can lead to corrupt data,
 deadlocks, etc.  As the set of functions safe to use in a handler is limited,