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
Patrick Horgan wrote, On 3.1.2011 7:11: 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
On 01/02/2011 10:53 PM, Václav Haisman wrote: 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