std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (12/16/89)
From: Doug Gwyn <uunet!smoke.brl.mil!gwyn> In article <7674@portia.Stanford.EDU> karish@forel.stanford.edu (Chuck Karish) writes: > The POSIX 1003.1 standard says that the types used for user and group > IDs (uid_t and gid_t, respectively) are to be `arithmetic types'. An > implementation or application that assumes that that the values are > always positive is broken. RONG. IEEE Std 1003.1 defines "group ID" and "user ID" to be NON-NEGATIVE integers in Section 2.3. This is in conformance with existing practice that Sun gratuitously ignored in their NFS implementation. Volume-Number: Volume 17, Number 101
karish@forel.stanford.edu (Chuck Karish) (12/16/89)
From: karish@forel.stanford.edu (Chuck Karish) In article <474@longway.TIC.COM> Doug Gwyn <uunet!brl.mil!gwyn> wrote: >From: Doug Gwyn <uunet!smoke.brl.mil!gwyn> >In article <7674@portia.Stanford.EDU> karish@forel.stanford.edu (Chuck Karish) writes: >> [something stupid] >IEEE Std 1003.1 defines "group ID" and "user ID" to be NON-NEGATIVE >integers in Section 2.3. This is in conformance with existing practice >that Sun gratuitously ignored in their NFS implementation. Hmmm. This could, indeed, cause problems. The original posting pointed out that that some vendors hedge on this issue by making the types unsigned short, so the negative values are cast to large (near USHRT_MAX) positive numbers. Of course, this will fail if a tar or cpio archive is unpacked on a system where uid_t and gid_t are signed types longer than 16 bits, so 65534 != -2. Who's going to change? For that matter, will other 1003.1 semantics be compromised to accomodate NFS as a transparent file access standard? Stay tuned... Chuck Karish karish@mindcraft.com (415) 323-9000 karish@forel.stanford.edu Volume-Number: Volume 17, Number 105
guy@auspex.uucp (Guy Harris) (12/19/89)
From: guy@auspex.uucp (Guy Harris) >>IEEE Std 1003.1 defines "group ID" and "user ID" to be NON-NEGATIVE >>integers in Section 2.3. This is in conformance with existing practice >>that Sun gratuitously ignored in their NFS implementation. > >Hmmm. This could, indeed, cause problems. > >Who's going to change? All together now: "fixed in 4.1" (unless they've ripped the fix out since I left). SVID says it's an unsigned type, and SunOS 4.1 is intended to be SVID-conformant, at least at the BA_OS and, I think, KE_OS level. If that causes problems with "tar" or "cpio" archives, well, you can't make even a SVID-compliant omelet without breaking a few eggs.... Volume-Number: Volume 17, Number 109