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.
Donn
-----Original Message-----
From: Ted Baker [mailto:yyyyy@xxxxxxxxxxxxxx]
Sent: Tuesday, March 13, 2001 10:26 AM
To: Donn Terry; yyy@xxxxxxxxxxx; yyyyyyy@xxxxxxxxxxxxxxxxxxxxx
Cc: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: RE: Comments on XBDd5 ERN 322
| ... you just can't cram 64 bits of data into 32 bits; if you
| could, we wouldn't have this problem ...
So, why not use a 64-bit (long integer) value to hold them?
This sure sounds like a case of a person who has decided to tie
one hand behind his back insisting that everyone else do the same.
If you have some peculiar reason you want to flout the dictates of
logic and make long integer still be only 32 bits in an
environment where you have lots of logically 64-bit values, for
some particular product, you can do so. Just don't ask everyone
to start calling this oddball new system POSIX compliant.
--Ted
|