C99: stdint.h, unsigned integers, and padding bytes
Greg Falcon
(other than unsigned char) may have padding bits.
TC2 modifies 17.8.1.1, the section on stdint.h, to say that the
uint32_t typedef is optional but must be defined if the implementation
provides a 32-bit unsigned integer type with no padding bits.
However, the definition of uintN_t at 17.8.1.1 does not mention
padding bits at all (compare this to the definition of intN_t, which
does).
The result of this is that if an implementation provides a 32-bit
unsigned int with padding bits, it is allowed (but not required) to
define uint32_t as a typedef for this type. Surprisingly, uint32_t
does not make the same no-padding-bits guarantee that int32_t
provides.
Is this really what was intended?
Greg F
Wojtek Lerch
news:67d5195a-1190-447b...@k26g2000vbp.googlegroups.com...
> The result of this is that if an implementation provides a 32-bit
> unsigned int with padding bits, it is allowed (but not required) to
> define uint32_t as a typedef for this type. Surprisingly, uint32_t
> does not make the same no-padding-bits guarantee that int32_t
> provides.
Well, 7.18.1#1 does promise that uint32_t and int32_t are "corresponding"
types as described in 6.2.5, and 6.2.5#6 says that corresponding types use
"the same amount of storage (including sign information)". Do you think by
"amount of storage" it's referring to the size or the width? (If the size,
why does "sign information" deserve to be mentioned but padding bits don't?
OTOH, if the width, why does the sign deserve to me mentioned at all?)
Greg Falcon
> Well, 7.18.1#1 does promise that uint32_t and int32_t are "corresponding"
> types as described in 6.2.5,
7.18.1#1 only makes this promise "when typedef names differing only in
the absence or presence of the initial u are defined". As far as I
can see, a system which has no int32_t typedef defined in <stdint.h>
can still have a uint32_t typedef to a type with padding bits, and yet
conform to the spec. I suspect this wasn't the intent, but I don't
see how the spec can be interpreted any other way.
Greg F
Wojtek Lerch
Um, 7.18.1#1 also says, "an implementation providing one of these
corresponding types shall also provide the other".
Greg Falcon
> Um, 7.18.1#1 also says, "an implementation providing one of these
> corresponding types shall also provide the other".
Of course it does. Sorry I missed that.
It's roundabout, but it looks like this is covered after all.
Thanks,
Greg F