[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210728193044.GR13220@brightrain.aerifal.cx>
Date: Wed, 28 Jul 2021 15:30:44 -0400
From: Rich Felker <dalias@...c.org>
To: Laurent Bercot <ska-dietlibc@...rnet.org>
Cc: musl@...ts.openwall.com
Subject: Re: Bug in src/signal/block.c
On Wed, Jul 28, 2021 at 05:11:11PM +0000, Laurent Bercot wrote:
> >> succeed since _NSIG will be 128 instead of 129.
>
> I happen to be in the process of updating my programming library
> performing workarounds for badly-specified parts of POSIX and related
> functions.
>
> NSIG is one of those parts. It is not specified by POSIX, but it is
> useful to have a walkable (as in, not 8*sizeof(sigset_t)) upper bound
> for the number of signals on a system.
I thought it was going to be POSIX-future, but maybe they did the ugly
_SC_NSIG-only approach instead (which partly defeats the purpose,
although you can use 8*sizeof(sigset_t) as an ugly upper bound on
NSIG where you need a constant expression).
> But NSIG is badly specified even across the systems where it exists.
> On glibc, it is 1 + the highest signal number. On FreeBSD and OpenBSD
> at least, it is the highest signal number.
That's unfortunate.
> musl appears to align on glibc; I suppose the value for MIPS will be
> updated to 129, for consistency.
No. The greatest signal number on mips is 127, not 128. There's a long
story behind this and it involves the kernel doing stupid stuff.
Inspect sys/wait.h if you want to try to figure it out yourself. :-)
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.
