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

Subject: Re: [Boost-users] [Off topic] Strict Aliasing white paper redux
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2011-01-03 03:08:23

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.

Patrick