On Sun, 2 Jun 2019 at 01:27, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>
> On 31/05/2019 19:55, Jens Maurer wrote:
> >>> What's the interaction with the existing library facility
> >>> <csignal>?
> >>
> > I didn't mean: how do I impplement the new facility, I'm asking about
> > (possibly existing) programs that currently use <csignal> in at
> > least some part, and another part now starts to use your proposed
> > new facility, which seems to offer notification of a similar set of
> > exceptional circumstances (e.g. SIGFPE).
> >
> > What does/should the specification say is supposed to happen?
> > (I don't care about implementation for now.)
>
> I was going to leave it as "implementation defined", so on some
> implementations mine uses <csignal> and thus conflicts with other code
> using signal(), but on other implementations they are totally independent.
>
> Is this acceptable to SG12?
>
> If not, and particularly if a majority on SG12 agrees me with that
> signal() is almost useless and almost no newly written production code
> written in the past 20 years has used it, would SG12 prefer to see a
> proposed wholesale replacement for signal(), which we send to deprecation?
>
> (Before someone asks "isn't that a WG14 C decision?", yes it is. However
> I had a few informal conversations at the London WG14 meeting, and it
> was widely agreed that signal() is not fit for purpose. However, it was
> also felt that sigaction() is too POSIX-specific to be standardised into
> C. So they are open to a proposed wholesale replacement, if it is
> generic and not platform-specific. Like my proposal)

Sounds plausible. Do we have any code search results about the use of signal()?