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

[Ralf Corsepius <ralf_corsepius at rtems dot org>]

On Thu, 2004-10-07 at 22:21, Jeff Johnston wrote:
> <sys/signal.h> is not defined by POSIX, ANSI, Single UNIX, or C99 so we're 
> largely in undefined territory here.  As previously noted, newlib's usage of the 
> sys directory doesn't necessarily match up with other C libraries out there.  It 
> seems to me the ultimate goal you want to achieve is to allow existing code 
> written against glibc that takes advantage of the fact that <signal.h> and 
> <sys/signal.h> are interchangeable.  An easy solution would be to add a check in 
> the default <sys/signal.h> that if _SIGNAL_H_ wasn't already defined, to include 
> <signal.h>.  Does that seem reasonable to you?
Hmm, not necessarily.

As you (correctly) say, "sys/signal.h" is undefined territory and
"off-standards". So, why would any code want to include <sys/signal.h>
at all and why should newlib care about?

IMHO, code including sys/signal.h either is non-portably relying on
something system-specific (Therefore it should be this code's duty to
cope with it) or it should be considered to be "just bugged".

Ralf