🚀 go-pugleaf

Submitted-by: martelli@cadlab.sublink.ORG (Alex Martelli)

Thanks to Donn Terry and the others responding, both here and by Email;
now I understand the S_ISUID/S_ISGID issue better!

donn@hpfcrn.fc.hp.com (Donn Terry) writes:
	...
:POSIX.1 says "On a regular file, [the S_ISUID] bit should be cleared
:on any write."  (P102, L684 and 688).  
:
:Two key things here:  "should" (not "shall") and "write" (not write() in
:italics). 
:
:"Should" is a recommendation, not a requirement.  Thus, a conforming
:system doesn't have to do it.  This is compromise wording, as some
:existing implementations would not conform if that was a requirement.
:(This is a consequence of the definition of "should".)
	...
:If you care, it's perfectly reasonable in a RFP (or any other purchase)
:to specify any "should" as a "shall" (or "shall not").  NIST did that in
:one place in FIPS 151-1.  X/Open has done it in several places.  In the

...but NOT here; indeed, digging into XPG3 I find in vol 2 pg 519 at the
end of the Description of write():  "...and if the file is a regular
file, the S_ISUID and S_ISGID bits of the file mode may be cleared".

Indeed, the "may" sounds to my non-native-speaker ears as even weaker
than the "should"...  so I guess that as a multiplatform application
developer I definitely HAVE TO learn to live with both behaviors (the
chmod() page of XPG3 also has threateninly mysterious caveats about what
is or is not done with S_ISUID/S_ISGID, so it won't necessarily be easy
to compensate for varying behavior of write() in this respect, alas...).

-- 
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

Volume-Number: Volume 23, Number 3