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

[Christopher Faylor <me at cgf dot cx>]

On Mon, Oct 04, 2004 at 06:47:03PM -0400, Jeff Johnston wrote:
>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?  I think most systems (at least the
>>ones I checked) tend to make sys/signal.h == signal.h.
>
>The basis of the current design is that signal numbers are considered OS 
>specific and newlib tries to separate such header information into sys 
>headers - the idea being that an OS using newlib simply overrides the sys 
>header file as needed.  Newlib doesn't have a bits directory - it has a 
>machine directory.  It also does not have an OS-specific header directory 
>like /usr/include/linux.  Is it fair to guess you are having problems with 
>applications that simply include <sys/signal.h> and not <signal.h>?

Someone just posted a patch for some software which added an '#ifdef
__CYGWIN__' and forced an include of <signal.h> rather than
<sys/signal.h>.  It had been a while since I looked at how this was laid
out and I was surprised to see a handful of definitions in signal.h with
the majority of definitions in sys/signal.h.

If this is system-specific stuff then some things should be moved out of
sys/signal.h, it seems.  It looks like sigset_t should be moved into
signal.h along with SIG_SETMASK, SIG_BLOCK, and SIG_UNBLOCK, sigaddset,
sigemptyset, and sigprocmask.

I'm not sure who's benefitting from this split, though.  AFAICT, the fact
that linux has a bits directory is irrelevant since the linux versions
of /usr/include/sys/signal.h and /usr/include/signal.h are the same thing.
How things are defined under the hood doesn't really matter as far as
the end-programmer is concerned.

cgf