Re: [Qemu-devel] [PATCH 5/5] linux-user/signal.c: define __SIGRTMIN/MAX for non-GNU platforms

[Natanael Copa]

On Tue, 29 Apr 2014 09:02:13 -0600
Eric Blake <address@hidden> wrote:

> On 04/29/2014 08:53 AM, Natanael Copa wrote:
> > On Tue, 29 Apr 2014 08:28:29 -0600
> > Eric Blake <address@hidden> wrote:
> > 
> >> On 04/29/2014 08:17 AM, Natanael Copa wrote:
> >>> The __SIGRTMIN and __SIGRTMAX are glibc internals and are not available
> >>> on all platforms, so we define those if they are missing.
> 
> >>> +#define __SIGRTMIN 32
> >>
> >> Rather than defining the implementation-specific __SIGRTMIN to a magic
> >> number that is liable to be wrong, why not instead fix the code to use
> >> the POSIX-mandated SIGRTMIN and SIGRTMAX public defines instead?
> >>
> > 
> > Those seems to be runtime values:
> > /usr/include/signal.h:#define SIGRTMIN  (__libc_current_sigrtmin())
> 
> Oh right - POSIX allows them to be runtime variable.  But we are
> interacting with a given kernel, where the values will be fixed.  Maybe
> you have to define __SIGRTMIN after all, but can we at least have an
> assert() that the value you picked matches SIGRTMIN at runtime?

Yeah, that might be an idea.

> > /usr/include/signal.h:#define SIGRTMAX  (__libc_current_sigrtmax())
> > 
> > so it gives:
> > /home/ncopa/src/qemu/linux-user/signal.c:93:5: error: nonconstant array 
> > index in initializer
> >      [SIGRTMIN] = __SIGRTMAX,
> > 
> > I could have used (NSIG-1) but are not sure if NSIG is a runtime macro
> > in glibc. The array itself is using _NSIG instead of NSIG for some
> > reason.
> 
> NSIG is not any more portable; nor does POSIX require that the RT
> signals occur at the tail end of NSIG (in other words, NSIG-1 need not
> be SIGRTMAX).  Unless someone knows of a kernel define, it sounds like
> we're stuck hard-coding in some knowledge of Linux.
> 

Since we already use _NSIG to define the size of the array, and we want
to use the last element of the array, maybe we should just use _NSIG-1?

-nc