NSIG wrong on Linux (amd64 and m68k, at least)

[Andreas Jaeger]

On 05/18/2012 08:15 PM, Thorsten Glaser wrote:
> Hi,
>
> I just noticed NSIG was 65 on Debian/m68k with (e)glibc, and looked,
> and it’s the same on amd64.
>
> hpa said that it’s probably an off-by-one error, that someone
> confused [32;64[ with [32;64] and that there are 32 RT signals
> on Linux/x86_64 but changing SIGRTMAX would be messy.
>
> The current source code still has this possible off-by-one:
> http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/bits/signum.h;h=3e485f6ed40ac289738e1a187a4732b45e61246b;hb=HEAD
> → line 68: #define _NSIG           65
>
> bye,
> //mirabilos, who’s doing too much libc work recently…

It was changed with this entry:
2003-03-31  Ulrich Drepper  <drepper@redhat.com>

         * sysdeps/unix/sysv/linux/alpha/bits/signum.h (_NSIG): Define 
to 65.
         * sysdeps/unix/sysv/linux/hppa/bits/signum.h (_NSIG): Likewise.
         * sysdeps/unix/sysv/linux/sparc/bits/signum.h (_NSIG): Likewise.
         * sysdeps/unix/sysv/linux/bits/signum.h (_NSIG): Likewise.
         (__SIGRTMAX): Adjust accordingly.


But where does this actually make a difference? We have:

#define _NSIG           65      /* Biggest signal number + 1
                                    (including real-time signals).  */

/* These are the hard limits of the kernel.  These values should not be
    used directly at user level.  */
#define __SIGRTMIN      32
#define __SIGRTMAX      (_NSIG - 1)

__SIGRTMAX is 64 and that's what counts, doesn't it?

Andreas
-- 
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126