std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/11/89)
From: uunet!BRL.MIL!gwyn In article <318@longway.TIC.COM> rja@edison.CHO.GE.COM writes: >I understand that there are some conflicts between ANSI C and the >1003.1 definitions, ... ANSI C doesn't address file permissions (other than implicitly to allow an open operation to fail if the permissions aren't right). Perhaps you're thinking of apparent conflicts wrt "environ" and the timezone stuff. Solutions to that have been devised. Volume-Number: Volume 16, Number 18
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/25/89)
From: uunet!auspex!guy (Guy Harris) >Probably. But what about the existing applications that depend on the >semantics of the older SVID? Are they out of luck, or will they be somehow >grandfathered in? If you plan to run one of those applications: $ su Password: # # # # Optimizing this to run "chmod" only on directories with the # # set-GID bit set is left as an exercise for the reader. # # # find / -type d -exec chmod g-s {} ";" # exit and live with the old semantics (and don't mount any remote file systems that support the new semantics). You may be able to restrict this to only those directories in which the applications in question will create files - how many such applications really exist? If you don't want to, or can't, change the permissions on the directories in question, then yes, I suspect those applications, and you, are out of luck. At best, there *might* be a binary-compatibility hack, but I would not be surprised if there were none. Volume-Number: Volume 16, Number 25
Don_Lewine@dgc.ceo.dg.com (08/15/90)
From: Don_Lewine@dgc.ceo.dg.com CEO summary: 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! Volume-Number: Volume 21, Number 30
gwyn@smoke.brl.mil (Doug Gwyn) (08/15/90)
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
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (08/16/90)
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
decot@hpisod2.cup.hp.com (Dave Decot) (08/16/90)
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