Re: [musl] Bug in src/signal/block.c

[Michael Forney <mforney@mforney.org>]

"Laurent Bercot" <ska-dietlibc@skarnet.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.