Must POSIX 1003.1 include files be standalone?

[Dave Decot]

Submitted-by: decot at hpcupt1.cup.hp.com (Dave Decot)

> Recently while working on the command sources of Andy Tanenbaums Minix 1.6
> (currently in beta and trying to become fully P1003.1 and .2 compatible),
> there appeared the question whether code like
> 
> 	#include <pwd.h>
> 	
> 	int main (void)
> 	{
> 	}
> 
> is required to work in a strictly conforming POSIX.1 implementation with
> Standard C Bindings. 

No.  But it is allowed to work.  Note that POSIX.1 permits any symbols
ending in _t, including uid_t, to appear in any of its headers (i.e.,
those not imported from ANSI C).

> The problem is as follows:
> 
> 	<pwd.h> contains a prototype for struct passwd *getpwuid (uid_t)
> 	and doesn't include <sys/types.h> by itself. I'm not shure if the
> 	above program needs to #include <sys/types.h> itself or <pwd.h> is
> 	wrong. From P1003.1-1988 <sys/types.h> needs to be included only if
> 	the program uses getpwuid().

To conform to POSIX.1-1988 or POSIX.1-1990, the program has to include
<sys/types.h> first.

> The same problem occurs in several other headers: e.g. <signal.h>, <grp.h>,
> <unistd.h>, <sys/wait.h>.

Same applies to them.

> Does P1003.1-1990 specify the correct behaviour?

It is clearer in this regard, although POSIX.1-1988 also required
that the prerequisite #includes be there as well.

POSIX.1-1991 will *require* that implementations provide stand-alone
headers.  In addition, a program will need to include *at most* one header
in order to use a particular function (the one that contains the prototype
for the function).

Dave Decot


Volume-Number: Volume 23, Number 73