On Tue, 13 Mar 2001 10:48:01 -0800 Donn Terry <yyyyyy@xxxxxxxxxxxxx>
wrote:
> I just had a very interesting insight.
>
> The 1996 standard says that uid_t (et al.) are "arithmetic types". Any
> program that either prints a value with a %d or %ld, or which assigns a
> uid_t to an integral type (specifically long) (with the consequent loss of
> significance that might occur if uid_t was really a double) is already
> nonconforming and should be fixed to conform with the 1996 standard.
>
> If, however, it DOESN'T break type on uid_t (including portably printing it
> if it needs to) then it's going to conform even if uid_t is changed to a
> type wider than long.
>
> I think we can reasonably say that notice that uid_t shouldn't be assumed to
> be a long was served (if not as loudly as some might wish) when the 1990
> (probably 1988) standard was published.
I find this very hard to swallow. The standard is composed not only
of normative text, but also of rationale (hopefully) clarifying what
people were thinking when the normative language was written. Saying
that the 1990 standard "served notice" that "uid_t should not be
assumed to be a long" is true, but the implication drawn in the
present context is patently false.
I typed(*) in the rationale for uid_t. Note in particular the
2nd and 4th paragraphs. In 1990, notice was served that uid_t
and gid_t might be shorter than short, *NOT* that they could
be expected to be longer than long.
Josh Knight
yyyy@xxxxxxxxxxxxxx
(*) There may be typos but "types to were changed" is in my printed
copy ISO/IEC 9945-1, IEEE Std 1003.1 First edition 1990-12-07,
whence the [sic]
- - - - B.2.5, p. 215, lines 1291-1314 - - - - -
uid_t Before the addition of this type, the data types used to
to represent these values varied throughout early drafts.
The <sys/stat.h> header defined these values as type short,
the <passwd.h> file (now <pwd.n> and <grp.h>) used an int,
and getuid() returned an int. In response to a strong
objection to the inconsistent definitions, all the types
to [sic] were switched to uid_t
In practice those historical implementations that use varying
types of this sort can typedef uid_t to short with no serious
consequences.
The problem associated with this change concerns object
compatibility after structure size chagnes. Since most
implementations will define uid_t as a short, the only
substantive change will be a reduction in the size of the
passwd structure. Consequently, implementations with an
overriding concern for object compatibilty can pad the
structure back to its current size. For that reason, this
problem was not considered critical enough to warrant the
addition of a separate type to POSIX.1.
The types uid_t and gid_t are magic cookies. There is no
[UID_MAX] defined by POSIX.1, and no structure imposed on
uid_t and gid_t other than that they be positive arithmentic
types. (In fact they could be unsigned char.) There is no
maximimum specified for the number of distinct user of group IDs.
|