🚀 go-pugleaf

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

In article <11188@cs.utexas.edu> From:  Don_Lewine@dgc.ceo.dg.com
>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)?

Yes, there can be a problem any time an extra header is included,
if there is no guarantee as to the identifiers that the header may
usurp.  No POSIX implementation can require an application to use
any facilities beyond what the POSIX standard requires for the
application, so if in fact UNIX System V were to need the extra
header (which it doesn't), it would not be POSIX compliant.  Note
that the means by which a POSIX-conforming compilation/execution
environment is obtained on your system may be nonobvious..

Volume-Number: Volume 21, Number 32

From:  Bob Goudreau <goudreau@larrybud.rtp.dg.com>

In article <11188@cs.utexas.edu>, Don_Lewine@dgc.ceo.dg.com writes:
>
> 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.
>  
> 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)?
>  
> 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!

At least for the case of implementations claiming to conform to ANSI C,
POSIX.1-1988 does indeed require that <unistd.h> must contain a
prototype for setuid().  Here's the relevant text, from section 2.8.3:

	Implementations claiming C Standard Language-Dependent Support
	shall declare function prototypes for all functions.

	Implementations claiming Common Usage C Language-Dependent
	Support shall declare the result type for all functions not
	returning a "plain" _int_.

	These function prototypes (if required) shall appear in the
	headers listed below.  If a function is not listed below, it
	shall have its prototype appear in <unistd.h>, which is
	presumed to be #include-ed whenever any function declared in it
	is used, whether or not it is mentioned in the Synopsis
	section for that function.
 
------------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA


Volume-Number: Volume 21, Number 35

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