Re: Moving everything from signal.h to sys/signal.h

[Christopher Faylor <me at cgf dot cx>]

On Mon, Oct 04, 2004 at 05:48:54AM +0200, Ralf Corsepius wrote:
>On Mon, 2004-10-04 at 00:12, Christopher Faylor wrote:
>> Is there any reason why there are a handful of definitions in
>> libc/include/signal.h while most of the signal definitions are in
>> libc/include/sys/signal.h?
>signal.h's behavior is defined by standards (POSIX)
>
>sys/signal.h is an implementation detail used to hide away
>arch-dependent details from signal.h

Did you look at what's in /usr/include/signal.h in newlib right now?

>>I think most systems (at least the ones I checked) tend to make
>>sys/signal.h == signal.h.
>Hmm?  All the ones I checked, do not.  Neither Linux, Solaris nor
>Freebsd.

I don't know what version of linux you're looking at but I just
checked an old version of Debian, RH9, and Fedora.  They all have
a dummy version of /usr/include/sys/signal.h that looks like this:

#include <signal.h>

/usr/include/sys/signal.h is linked to /usr/include/signal.h on OSF/1.

Here's the contents of /usr/include/signal.h on HP/UX 9:

/* @(#) $Revision: 64.2 $ */
#ifndef _SIGNAL_INCLUDED /* allow multiple inclusions */
#define _SIGNAL_INCLUDED

#include <sys/signal.h>

#endif /* _SIGNAL_INCLUDED */

I didn't look at Solaris before but, you're right that the two files
are different.  Their differences are much more substantial than
newlib's though.

I don't know why such things as SI_USER and SA_SIGINFO would be defined
in newlib's sys/signal.h and SIG_IGN would be only defined in signal.h.

I don't think there is any consistent rationale for the current
separation.

cgf