On 02/06/2019 21:43, JF Bastien wrote:
> This is probably the best starting point, even if not that great:
> https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=signal&search=Search

I spent some time trawling through the source codes of various results
returned by that index, and I would categorise the use cases of signal()
thusly, in order of common use:

1. Convenience default parametered overload for sigaction(), which is
fiddly to call. You can tell this code by people intermixing sigaction()
and signal() in order to save typing boilerplate for sigaction().

2. Specific use of signal() with POSIX semantics i.e. one of the
optional choice of semantics in the C and C++ standards. These were
overwhelmingly crash dumpers saving out extra metadata with the core dump.

3. Fallback when sigaction() is not available.

4. Specific support for Win32, with domain knowledge of Win32's
historically awful signal() implementation baked into the source code. I
can only assume that the author could not, or would not, use Win32 SEH.

5. "Portable" code for when not on POSIX. I noticed in the three
examples or so of this which I found that the author specifically
assumes that non-POSIX signal() has POSIX semantics, and not the
extremely restricted portable semantics permitted by the C and C++
standards. I would suggest that such code was written for completeness,
and not actually used.


Finally there were quite a few colourful source code comments about how
broken signal() is, specifically the problem that when signal() handlers
are invoked, the implementation may, or may *not*, reset the signal
handler to default, thus causing a small window of time before you can
reset the handler when your program may terminate. Which ruins the
entire point of signal handling, which is to make more reliable software.

Incidentally, until POSIX.2017, it was not permitted to ever call
signal() in a multithreaded program. It is still explicitly not
permitted by the C and C++ standards, in fact it is *required* that the
implementation ignores signal() in a multithreaded program according to
the current C2x working draft. I can't think of any implementation which
conforms to that requirement however.


Given all of the above, I think that I shall redraft my proposal paper
to rock on and propose a complete replacement for <csignal>. Or, rather,
programs get a choice: (i) use <csignal> OR (ii) use the new facilities,
with it being UB if a program ever uses both for the same signal number
at the same time.

Thanks for your feedback everyone.

Niall