[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250608184932.GN1827@brightrain.aerifal.cx>
Date: Sun, 8 Jun 2025 14:49:32 -0400
From: Rich Felker <dalias@...c.org>
To: Bobby Bingham <koorogi@...rogi.info>
Cc: musl@...ts.openwall.com
Subject: Re: The `sigpause` function behavior does not fully comply
with the POSIX specification
On Sun, Jun 08, 2025 at 01:39:17PM -0500, Bobby Bingham wrote:
> On 6/8/25 12:09, Rich Felker wrote:
> > > >
> > > > See https://pubs.opengroup.org/onlinepubs/9699919799/functions/
> > > > sigpause.html for POSIX.1-2018
> > > > where EINVAL is allowed and sigpause returns SIG_ERR (defined by musl in
> > > > <signal.h> to ((void (*)(int))-1) ).
> > >
> > > That page says:
> > >
> > > The sigpause() function shall suspend execution of the thread until
> > > a signal is received, whereupon it shall return -1 and set errno to
> > > [EINTR].
> > >
> > > This reads to me that sigpause is only permitted to set errno to EINTR, and
> > > not to return other errors. The list of errors would seem to apply to the
> > > other functions on the page, which are documented to "use errno to indicate
> > > the error."
> >
> > That's specifying the behavior on successful return, not on errors.
>
> Quoting the entire RETURN VALUE section:
>
>
> Upon successful completion, sigset() shall return SIG_HOLD if the
> signal had been blocked and the signal's previous disposition if it
> had not been blocked. Otherwise, SIG_ERR shall be returned and errno
> set to indicate the error.
>
> The sigpause() function shall suspend execution of the thread until
> a signal is received, whereupon it shall return -1 and set errno to
> [EINTR].
>
> For all other functions, upon successful completion, 0 shall be
> returned. Otherwise, -1 shall be returned and errno set to indicate
> the error.
>
>
> For all the other functions, the documentation clearly distinguishes between
> successful completion and errors, and states what return value indicates
> that an error occurred. For sigpause, it does not. As you stated, the
> documentation here specifies what happens on success -- there is no mention
> of what the return value is on failure.
>
> I took this to mean that sigpause cannot report errors, and therefore cannot
> fail.
>
>
> >
> > The ERRORS section says:
> >
> > These functions shall fail if:
> >
> > [EINVAL]
> > The sig argument is an illegal signal number.
> >
> > Seems pretty clear. This is a "shall fail" (mandatory) not a "may
> > fail", so detecting the invalid signal number and failing with EINVAL
> > is mandatory. The old behavior of ignoring it was non-conforming.
>
>
> I did read that. I found it hard to reconcile a "shall fail" error for a
> function that does not have a documented way to report errors, so thought
> perhaps the phrasing "these functions" was intended to refer to just those
> functions on the page _that can report errors_.
>
> One can certainly read between the lines and infer that a return value of -1
> can indicate an error. I just expected it to explicitly say so if that was
> the case. But I'm not an expert at reading the POSIX spec; perhaps my
> expectation is wrong. Or perhaps the wording for this function was just
> unusually sloppy.
This would probably call for an interpretation, except that the
functions were removed from the standard and the standard no longer
has anything to say about them. So I'm not sure what's best to do.
If the historical precedent in other implementations is for not
reporting an error here, and applications are expecting that, perhaps
we should revert the change?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
