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

[Patrick Horgan]

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