ANSI vs POSIX on <sys/types.h>

[Andy Tanenbaum]

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

In article <712 at longway.TIC.COM> Doug Gwyn <gwyn at smoke.brl.mil> writes:
><signal.h> must not define extra garbage such as the kill() interface
>or the POSIX *_t typedefs, except under control of some "feature test
>macro" such as _POSIX_SOURCE.  In the case of the typedefs, I would
>urge that they not be defined as a side effect of #including <signal.h>
>even in the presence of _POSIX_SOURCE.  You don't need pid_t to properly
>declare getpid() or kill() in an implementation; instead, simply use the
>equivalent type derived from basic types (in this case, probably "int").

POSIX specifically defines kill's first argument as type pid_t, so it
would seem to be poor programming practice to use int, even if this is legal.
If one replaced the *_t types by their definitions everywhere, then a
decision to change pid_t from, say, int, to, say, long, would require
a real expert to dig through all the code to find those int's that really
are pid_t's.  Maintenance of such code would be exceedingly difficult.
I think that the only realistic way is to use pid_t in the prototype of 
kill.  This prototype is required in <signal.h> (protected by
#ifdef _POSIX_SOURCE).

This then raises the question of how to make pid_t known.  In the example
implementation given, <sys/types.h> is included in raise.c.  If this is
indeed legal, then that is clearly one way to do it, as presumably all the
names introduced by <sys/types.h> are not present in the object file,
raise.o, and thus do not pollute the name space.

However, why do you urge not to put #include <sys/types.h> into <signal.h>
under protection of #ifdef _POSIX_SOURCE?

Andy Tanenbaum (ast at cs.vu.nl)

Volume-Number: Volume 20, Number 23