ANSI vs POSIX on <sys/types.h>

[Andy Tanenbaum]

From:  Andy Tanenbaum <ast at cs.vu.nl>

We have gone through this before, but I still haven't gotten an unambiguous
answer.  Let me try a specific example to make it clearer.

Suppose you want to write a routine raise() that is ANSI conformant and also
POSIX conformant.  Raise calls the POSIX kill function, so it includes
<signal.h>.  The <signal.h> header contains the prototype for kill(), which
uses pid_t, a type defined in <sys/types.h>.  POSIX mandates <sys/types.h>
but ANSI does not require it.  Thus it is probably not ANSI-legal to put

#include <sys/types.h>

in raise(), since an ANSI routine cannot depend on something that ANSI
doesn't require.  The raise routine would not be portable then, and maybe
not even conformant.  On the other hand, putting the #include in <signal.h>
probably isn't legal either, and certainly not portable to non POSIX
systems.  

The question is: it has to go somewhere, but where?  I have thought about
putting it in <signal.h> but protected by #ifdef _POSIX_SOURCE, just as
the prototype for kill is.  However, our earlier discussion in this group
suggested that this wasn't legal either.  Does anybody know what the story
is?

Andy Tanenbaum (ast at cs.vu.nl)

Volume-Number: Volume 20, Number 20