Paul Eggert wrote: > The only place those > types appear is in a stdbit.in.h comment. Come to think of it, that > comment's types should be changed to match the code; done in the first > attached patch.
OK. > > Yes, this is my confusion: If, say, uint16_t does not exist at all, how > > is uint_least16_t represented? > > On such platforms it's an unsigned integer type containing at least 17 > value bits. There may be padding bits. It has the smallest number of > value bits among all such unsigned integer types. > > For example, on the B5000 architecture I mentioned, uint_least16_t would > be equivalent to unsigned int, which has 39 value bits, as that machine > supports unsigned arithmetic as the low-order 39 bits of a 48-bit > machine word. I see. Thanks for explaining. > > And do we have to write> x & 0xFFFFU > > instead of > > (uint16_t) x > > then? > > Yes, if X might exceed 2**16. I see. > > And similarly, will a conversion (implicit or cast) from > > uint_least16_t to int_least16_t extend the sign bit? > > It is like converting unsigned int to int: if the value in question > exceeds INT_LEAST16_MAX, in C99 and later the result is > implementation-defined or an implementation-defined signal is raised. > (C89 did not allow for the signal.) > ... > this should be documented; done by installing the 3rd attached patch. Thanks. Bruno
