Re: Anyone object to the following change in libc?

Bruce Evans wrote:
> On Thu, 30 Oct 2003, Garrett Wollman wrote:
> > More specifically: IEEE Std. 1003.1-2001 is aligned to ISO/IEC
> > 9899:1999 in all respects.  C99 alignment was one of the principal
> > reasons for bringing out a whole new standard in the first place,
> > rather than continuing the amendment process.  (This is also why POSIX
> > now requires eight-bit bytes.)
> 
> This doesn't follow, since C99 doesn't require 8-bit bits.  int8_t is
> optional in C99 and all code that uses it unconditionally is unportable.
> Similarly for most other types in <stdint.h>.  The required ones are
> [u]int_least{8,16,32,64}_t and [u]int_fast{8,16,32,64}_t and [u]intmax_t,
> i.e., nothing that can't be declared in C90 except a 64-bit type.

I believe that you meant to say uint8_t is optional, and int8_t is
required (see /usr/src/sys/*/include/_types.h).  I think this was a
concession to IBM, which defaulted to unsigned characters, and
lacked a "signed" keyword in its compilers.

> POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
> integer types exist.  It says that the existence of int8_t implies
> that a byte is 8 bits and CHAR_BIT is 8.  I'm not sure what prevents
> int8_t being smaller than char.

I think this comes down to the requirement for intergral arithmetic
types.

Someone asked for a 64 bit ino_t a while back, and wanted the thing
so they could squirrel away a cookie for themselves in the high 32
bits.  On a 32 bit system, long long is not an integral artihmetic
type; if you pick the intersection of ISO C and POSIX (which requires
that ino_t be one of these types), then you are left with a 32 bit
value.  On an LP64 (vs. an ILP64) system, you are also screwed, if
you want binary compatabilty.  You also have to have 32 bit variants
for ABI compatability (assuming you still want to run 32 bit apps),
so you are thrice damned, since you will need to support a 32 bit
to 64 bit conversion to support the ABI32, and in doing, you will
have come up with a method which will work just as well to support
your 32 bits of cookie with a 32 bit ino_t in 64 bit mode.

FWIW, this same logic applies here: you can't have a char > 8bits,
because if you did so, you would not have a valid arithmetic integral
type from which to create 8bit-sized things that must be one of those
types.

This pretty much guarantees that if you have *any* 32 bit values for
standards defined parameters/structure members for API's, you are
nailed to the LP64 cross, and can never go ILP64 safely so long as
you intend to support those API's.  POSIX has a number of these,
BTW, which is why Sun didn't go whole-hog on the API's, and instead
defined things like "stat64", etc. (yes, I know, off_t and size_t do
not have this restrictionl; some structure members do, though...).

-- Terry