home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0037.txt < prev    next >
Encoding:
Internet Message Format  |  1990-10-26  |  1.9 KB
  1. From:  decot@hpisod2.cup.hp.com (Dave Decot)
  2.  
  3. > I have been comparing SVID Issue 3 (for V.4) to IEEE Std 1003.1-1988. 
  4. > I noticed that the SVID specifies header files in the synopsis for 
  5. > various functions that are not required for POSIX.  For example,
  6. > POSIX says that setuid() requires that <sys/types.h> be included.  
  7. > The SVID requires that both <sys/types.h> and <unistd.h> be included.
  8.  
  9. POSIX.1-1988 also says that <unistd.h> is required, but it says it
  10. elsewhere, in section 2.8.3:
  11.  
  12.     If a function is not listed below, it shall have its prototype
  13.     appear in <unistd.h>, which is presumed to be #included-ed whenever
  14.     any function declared in it is used, whether or not it is mentioned
  15.     in the Synopsis section for that function.
  16.  
  17. > Question: Is there anything wrong with this?  If I write a strictly
  18. > conforming application, can I include <unistd.h> for SVID 
  19. > compatibility even if POSIX does not require it?  Is there any 
  20. > problem with including "extra" header files (other than the obvious 
  21. > restrictions on the namespace)?
  22.  
  23. You can always include any POSIX.1 header wherever you want in a POSIX.1
  24. conforming program (except where it would cause a syntax error, such as
  25. in the middle of a declaration or statement :-).
  26.  
  27. > BTW, looking at the SVR4 code there is nothing in <unistd.h> that 
  28. > would require it to be included for setuid().  There do not seem to 
  29. > be any symbols in the header file that are prohibited.  However, this 
  30. > is a standards questions and reading the .h files is cheating!
  31.  
  32. The declaration or function prototype for setuid() must appear
  33. in <unistd.h>, and the application must #include it.  In some cases,
  34. the header might contain a faster macro version of the function.
  35.  
  36. Future versions of POSIX.1 will not require the application to #include
  37. <sys/types.h> for any purpose, since any needed types for a given function
  38. will also be available from the header which declares that function.
  39.  
  40. Dave Decot
  41.  
  42. Volume-Number: Volume 21, Number 38
  43.  
  44.