Re: Possible gcc bug in strict type aliasing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27/09/16 13:49, Vincent Lefevre wrote:
> On 2016-09-26 10:32:14 +0100, Andrew Haley wrote:
>> On 25/09/16 22:46, David Brown wrote:
>>
>> I think the bug is here:
>>
>>>        temp = *t2p;      // Read as T2
>>>        t1p2 = (T1*)t2p;  // Visible T2 to T1 pointer conversion
>>>        *t1p2 = temp;     // Write as T1
>>
>> 6.3.2.3 Pointers
>>
>> 7 A pointer to an object type may be converted to a pointer to a
>>   different object type. If the resulting pointer is not correctly
>>   aligned for the referenced type, the behavior is undefined.
>>   Otherwise, when converted back again, the result shall compare equal
>>   to the original pointer.
>>
>> Note that you have permission only to convert the pointer back to the
>> original type and compare it.  You don't have permission to
>> dereference it as a different type.  IMO your program is undefined.
> 
> I disagree. The above paragraph says nothing about dereferencing the
> pointer; in particular, it does not disallow one to dereference it
> as a different type.

Perhaps you are right with regard to original intent, but if so it's
very oddly worded.

AIUI without any explicit description of what should happen in any
situation, all bets are off.  This is the usual way of writing
language specifications, and indeed standards in general.  6.3.2.3
does not say that the converted pointer may be used for anything other
than an equality comparison; if there was the intention that anything
else was possible, why only mention equality comparisons?

Andrew.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux