Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley <a...@redhat.com> writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I understand it. That is
clearly the assumption on which the code relies.
But in the new compilers it's an integer type, not a character
type--from the spec:
7.18.1.1 Exact-width integer types
1 The typedef name intN_t designates a signed integer type with width N
, no padding
bits, and a two’s complement representation. Thus, int8_t denotes a
signed integer
type with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type with
width N . Thus,
uint24_t denotes an unsigned integer type with a width of exactly 24 bits.
3 These types are optional. However, if an implementation provides
integer types with
widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed
types) that have a
two’s complement representation, it shall define the corresponding
typedef names.
Patrick
