[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250609140644.GO1827@brightrain.aerifal.cx>
Date: Mon, 9 Jun 2025 10:06:44 -0400
From: Rich Felker <dalias@...c.org>
To: Valery Ushakov <uwe@...err.spb.ru>
Cc: musl@...ts.openwall.com
Subject: Re: Re: The `sigpause` function behavior does not fully
comply with the POSIX specification
On Mon, Jun 09, 2025 at 02:20:52PM +0300, Valery Ushakov wrote:
> On Sun, Jun 08, 2025 at 14:49:32 -0400, Rich Felker wrote:
>
> > 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?
>
> sigpause is a 4.3BSD interface and it used to be a system call that
> did this:
>
> https://www.retro11.de/ouxr/43bsd/usr/src/sys/sys/kern_sig.c.html#s:_sigpause
>
> sigpause()
> {
> struct a {
> int mask;
> } *uap = (struct a *)u.u_ap;
> register struct proc *p = u.u_procp;
>
> /*
> * When returning from sigpause, we want
> * the old mask to be restored after the
> * signal handler has finished. Thus, we
> * save it here and mark the proc structure
> * to indicate this (should be in u.).
> */
> u.u_oldmask = p->p_sigmask;
> p->p_flag |= SOMASK;
> p->p_sigmask = uap->mask &~ cantmask;
> for (;;)
> sleep((caddr_t)&u, PSLEP);
> /*NOTREACHED*/
> }
>
>
> Which also brings up another question. The current NetBSD man page
> documents that behavior in https://man.netbsd.org/sigpause.3 as
> (emphasis mine):
>
> sigpause() ASSIGNS sigmask to the set of masked signals and then waits
> for a signal to arrive;
>
>
> While POSIX says:
>
> The sigpause() function shall REMOVE sig from the signal mask of the
> calling process and suspend the calling process until a signal is
> received.
>
> Which is not what historic sigpause(2) did, if i read this text (and
> "sigdelset" in implementations) correctly.
The POSIX text seems to be missing any rationale explaining this, but
I found it's actually explained in the Linux man pages. This is one
place where there were historical mismatched bsd and sysv interfaces
by the same name, and POSIX codified the sysv one. So if we're looking
at historical behaviors, it probably only makes sense to look at
implementions that follow sysv practices.
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.
