[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <222WPE66U74QU.3HRJMZ5QFQOAF@mforney.org>
Date: Wed, 28 Jul 2021 11:43:29 -0700
From: Michael Forney <mforney@...rney.org>
To: musl@...ts.openwall.com
Subject: Re: Bug in src/signal/block.c
"Laurent Bercot" <ska-dietlibc@...rnet.org> wrote:
> 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.
>
> 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.
The current draft of POSIX issue 8 includes a resolution for
https://www.austingroupbugs.net/view.php?id=741 (Add a NSIG constant
(or, alternatively, SIGMAX))
However, rather than adding NSIG, they introduced a new sysconf
variable _SC_NSIG, defined as the highest supported signal number
+ 1, and NSIG_MAX, which is defined as follows:
Maximum possible return value of sysconf(_SC_NSIG). See XSH sysconf().
The value of {NSIG_MAX} shall be no greater than the number of
signals that the sigset_t type (see <signal.h>) is capable of
representing, ignoring any restrictions imposed by sigfillset() or
sigaddset().
They probably went with this route instead of specifying NSIG due
to those inconsistencies you mentioned. Unfortunately, as far as
I'm aware, both _SC_NSIG and NSIG_MAX are not yet present in any
libc.
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.
