Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.