Harald van Dijk wrote:
(e-mail address removed) wrote:
Tom St Denis wrote:
Frederick Gotham wrote:
Here's an excerpt from the Dinkumware library reference:
__________
| uint8_t, uint16_t, uint32_t, uint64_t
|
| The types each specify an unsigned integer type
| whose representation has exactly eight, 16, 32,
| or 64 bits, respectively.
__________
How could that be possible if we had a 36-Bit system such as the
following?
char: 9-Bit
short: 18-Bit
int: 36-Bit
long: 36-Bit
The uint types are OPTIONAL. If they exist they are guaranteed to
be a given size [or at least represent the given range, padding
bits omitted...].
This is why using them is dangerous since any C99 conforming
compiler could not have them.
Types like uint32_t are required if the implementation
has a standard integer type that matches it.
Two nits: uint32_t is required if the implementation has an integer
type (standard integer type or extended integer type) that matches it,
Yes. Notice I spelled if with only one f.
and the
implementation also has an integer type that matches int32_t.
That's not how I read the requirement. An int32_t must
be provided if there's a type that matches it; a uint32_t
must be provided if there's a type that matches it; but
either can be required without the existence of the other.
7.18.1p1:
"When typedef names differing only in the absence or presence of the
initial u are defined, they shall denote corresponding signed and
unsigned types as described in 6.2.5; an implementation providing one of
these corresponding types shall also provide the other."
Interesting. This can be read either as saying that
an implementation can't provide uint32_t unless it
also provides int32_t (and vice versa), or as saying
that if an implementation has a type that matches
uint32_t it must also provide a type that matches
int32_t (and vice versa) (and similarly for 8,16,64).
I'll admit 7.18.1.1p3 is ambiguous, but your (unfortunately legitimate)
interpretation of it leads to ridiculous results, such as any
implementation with CHAR_BIT==8 and no two's complement being
nonconforming.
An implementation with CHAR_BIT==8 and ones complement
for signed char would simply be required to have an
extended integer type with size 1 and that uses twos
complement for its signed type.