Re: [Boost-users] [Off topic] Strict Aliasing white paper redux

Subject: Re: [Boost-users] [Off topic] Strict Aliasing white paper redux
From: Václav Haisman (v.haisman_at_[hidden])
Date: 2011-01-03 04:45:32

 On Mon, 03 Jan 2011 00:08:23 -0800, Patrick Horgan <phorgan1_at_[hidden]> 
 wrote:
> On 01/02/2011 10:53 PM, Václav Haisman wrote:
>> Patrick Horgan wrote, On 3.1.2011 7:11:
>>> Some time ago, I posted a link here to my (then new) white paper on
>>> strict-aliasing.  I wrote it because people keep posting, on this 
>>> and on
>>> other lists, questions that show a basic misunderstanding of 
>>> aliasing and
>>> what the rules in C and C++ standards on aliasing are intended to
>>> communicate.  I got some great feedback and have posted a new 
>>> revision,
>>> http://dbp-consulting.com/StrictAliasing.pdf.  I'm hoping that 
>>> people on this
>>> list will review the paper and tell me some more ways of improving 
>>> it.  My
>>> intention is to write a paper that will make it so that I won't 
>>> have to keep
>>> answering the same questions over and over again;)  I'll just point 
>>> people at
>>> the paper.
>> Nice paper. But I believe parts are wrong or misleading. Misleading 
>> is the
>> part about -fno-strict-aliasing. It is GCC specific.
> That's a good point, and I thought about that when writing it, but so
> far, it seems that only gcc is giving warning messages about
> strict-aliasing.  At least when googleing they are the only ones I
> see.  You're right though that I should point out that it is a gcc
> specific option.
>>   The wrong part, I think,
>> is the part suggesting union as a solution. As far as I know you can 
>> only
>> read from union through a member that you have put into it. The fact 
>> that you
>> can access different union member is also an extension, though one 
>> more
>> common than just GCC specific.
> I'm not so sure.  This idiom has been around as long as unions were
> in C.  Do you know of any compilers that don't support it?  Of course
> memcpy or any other solution using character pointers would be
> supported, but compilers wouldn't generate efficient code for in this
> case a simple swap of 16 bit ints.  Clearly the specs say that a 
> union
> can only contain one object at a time.  Hmmm.  The C99 spec has a
> footnote to section 6.5.2.3/3 that seems to clearly say you can do
> this:
>
> 85) If the member used to access the contents of a union object is
> not the same as the member last used to store a value in the object,
> the appropriate part of the object representation of the value is
> reinterpreted as an object representation in the new type as 
> described
> in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be
> a trap representation.
>
> The current C++ spec doesn't say anything about this, so it seems to
> be a difference between C and C++, not a surprise, since C++ wants 
> you
> do do a delete and placement new to switch active members of a union.
> C++ unions get implicit copy constructors.  Nevertheless, it bothers
> me to think that a pod union would act differently in C and C++.
>
> I've CC'd a friend Nick Stoughton to see if he has any thoughts on 
> this.

 I conclude that from 9.5/1 (excerpt):

 "In a union, at most one of the data members can be active at any time, 
 that is, the value of at most one of the data members can be stored in a 
 union at any time. [Note: one special guarantee is made in order to 
 simplify the use of unions: If a POD-union contains several POD-structs 
 that share a common initial sequence (9.2), and if an object of this 
 POD-union type contains one of the POD-structs, it is permitted to 
 inspect the common initial sequence of any of POD-struct members; see 
 9.2. ]"

 There is the "at most one of the data members can be active at any 
 time". There is no allowance for access using a different member, except 
 for the case of the "common initial sequence", which is not the case 
 your paper discusses. Also, from 3.9.2/1:

 "— unions, which are classes capable of containing objects of different 
 types at different times, 9.5;"

 The important part is the "different types at different times". It 
 cannot hold both uint16_t and uint32_t at the same time.

 IANALL

-- 
 VH