Please don’t modify <csignal>. The content is usually outside the control of most C++ implementations.
Use a different header if you must do anything about signal handling.

— Gaby

> On Jun 3, 2019, at 1:48 PM, Niall Douglas <s_sourceforge_at_nedprod.com> wrote:
>
>> 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
> _______________________________________________
> ub mailing list
> ub_at_isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/ub