C99 stdint.h

[ena8t8si]

(e-mail address removed) wrote:

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.

Meaning if it has no such two's complement type, it cannot be conforming.
That's what I said, isn't it?

There's no reason an
implementation can't have both ones complement types
and twos complement types.

The standard doesn't prohibit it, but hardware limitations are a possible
reason.

No extra hardware needed. Just two 256-element tables,
one with int's, one with unsigned char's - an indexed
load to promote to int, an indexed copy byte to save
an int value as an int8_t.

I'm not sure if you mean 7.18.1p1 or 7.18.1.1p3, but either way

Right, 7.18.1.1p3.