This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?


Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley <aph@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]