ANSI vs POSIX on <sys/types.h>

[Doug Gwyn]

From:  Doug Gwyn <gwyn at smoke.brl.mil>

In article <714 at longway.TIC.COM> From:  Andy Tanenbaum <ast at cs.vu.nl>
>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.

You miss an important point -- we're talking about system code provided
by the IMPLEMENTOR, not application code.  Presumably the implementor
IS a real expert, and furthermore is in charge of the decision about
what specific typedefs will be used.  I suspect that many implementors
will provide (for implementation use only) additional headers, say
<sys/_types.h>, that define identifiers such as __pid_t that are just
like the POSIX ones but taken from the name space reserved for use by
implementations.  Then, for example, <sys/types.h> could contain:
	/* <sys/types.h>: */
	#include <sys/_types.h>
	#define pid_t __pid_t
and <signal.h> could contain:
	/* <signal.h>: */
	#include <sys/_types.h>
	#ifdef _POSIX_SOURCE
	extern int kill(__pid_t, int);
	#endif
which addresses the maintenance issue that the implementor might be
faced with.  (Applications are oblivious to all this substructure,
which is the way things SHOULD be.)

>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.

Yes, that was one of the points of the example.

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

Because I don't think that use of _POSIX_SOURCE should pollute the
name space beyond the minimum required for POSIX.

Volume-Number: Volume 20, Number 26