🚀 go-pugleaf

From:  decot@hpisod2.cup.hp.com (Dave Decot)

> I have been comparing SVID Issue 3 (for V.4) to IEEE Std 1003.1-1988. 
> I noticed that the SVID specifies header files in the synopsis for 
> various functions that are not required for POSIX.  For example,
> POSIX says that setuid() requires that <sys/types.h> be included.  
> The SVID requires that both <sys/types.h> and <unistd.h> be included.

POSIX.1-1988 also says that <unistd.h> is required, but it says it
elsewhere, in section 2.8.3:

    If a function is not listed below, it shall have its prototype
    appear in <unistd.h>, which is presumed to be #included-ed whenever
    any function declared in it is used, whether or not it is mentioned
    in the Synopsis section for that function.

> Question: Is there anything wrong with this?  If I write a strictly
> conforming application, can I include <unistd.h> for SVID 
> compatibility even if POSIX does not require it?  Is there any 
> problem with including "extra" header files (other than the obvious 
> restrictions on the namespace)?

You can always include any POSIX.1 header wherever you want in a POSIX.1
conforming program (except where it would cause a syntax error, such as
in the middle of a declaration or statement :-).

> BTW, looking at the SVR4 code there is nothing in <unistd.h> that 
> would require it to be included for setuid().  There do not seem to 
> be any symbols in the header file that are prohibited.  However, this 
> is a standards questions and reading the .h files is cheating!

The declaration or function prototype for setuid() must appear
in <unistd.h>, and the application must #include it.  In some cases,
the header might contain a faster macro version of the function.

Future versions of POSIX.1 will not require the application to #include
<sys/types.h> for any purpose, since any needed types for a given function
will also be available from the header which declares that function.

Dave Decot

Volume-Number: Volume 21, Number 38