Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 74.125.46.28 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding:sender;
        b=etFUhShw/QY4/s2d30XQTNiwHNW9y2tFAuaUskJwlA/e9OzuHs5EHMMb5fAY2lHUJS
         p1oaQcNHaYeJrFfcMHdHeaPjImmCbVjmW2Eb3As3f/3B5lOop9k8TkkyrznbK1RCuCE6
         sApABiarsECmDrBK9bG87Zs4/Ro9IGvYiF8+w=
Message-ID: <486416A5.1060607@roguewave.com>
Date: Thu, 26 Jun 2008 16:22:29 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r669735 - in /stdcxx/branches/4.3.x:
 include/rw/_meta_other.h
 include/type_traits tests/utilities/20.meta.trans.other.cpp
References: <20080619225234.8583F23889F7@eris.apache.org>
 <4861555E.7050104@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBF2@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBF2@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Travis Vitek wrote:
> Martin Sebor wrote:
>> vitek@apache.org wrote:
>>> Author: vitek
>>> Date: Thu Jun 19 15:52:34 2008
>>> New Revision: 669735
>>>
>>> URL: http://svn.apache.org/viewvc?rev=669735&view=rev
>>> Log:
>>> 2008-06-19  Travis Vitek  <vitek@roguewave.com>
>>>
>>> 	STDCXX-926
>> [...]
>>> +template <size_t _Size, size_t _Align = 
>>> __rw_default_alignment<_Size>::value>
>>>  struct __rw_aligned_storage
>>>  {
> 
> [...]
> 
>>>      typedef union {
>>> -        unsigned char __data [_Len];
>>> -        // not implemented
>>> +        unsigned char __size [_Size];
>>> +
>>> +        typename
>>> +        __rw_aligned_storage_impl<_Align>::_C_type __align;
>> I believe there are platforms where unions are aligned on
>> the boundary given by the first member. This one looks like
>> it might be one of them: http://tinyurl.com/472744. Unless
>> I'm mistaken we should switch the order of the two members
>> to make sure the union is properly aligned.
>>
> 
> I'm not absolutely sure I'm reading the documentation you linked to
> correctly, but here goes...

It's possible that I misread the text. I was pretty sure (and still
am) I remembered discussing the alignment issue before but I couldn't
(and still can't) find it in the archives. I pointed to this page
because that was the best I could come up with in the absence of
anything else. Maybe it's a red herring. It could also be that the
issue I think I'm remembering had less to do with alignment than
something else (aliasing, maybe), but given the choice between
placing the more strictly aligned type first and the unaligned
buffer second or doing laying them down in the reverse order I'd
go for the former even if there is no real issue.

I searched library headers and sources for how we define unions and
with the exception of limits_bits.cpp we always follow this rule.
Unless there is a reason not to make this change to aligned_union,
I think we should change both limits_bits.cpp and aligned_union to
always define the member with the more strict alignment requirement
first, just for peace of mind.

Is there any reason/advantage to having the char buffer first?

> 
> The first paragraph of that documentation says
> 
> Individual members of a union are mapped the same way as members of the
> structure. That is, each of the members, if not a union, is mapped as if
> it were a member of a structure.  This means that the first storage
> locations for each of the members of a union do not overlay each other
> if each of the members requires different alignment and therefore
> different padding before the beginning of the member.
> 
> This violates C99 (6.7.2.1 p5)

Not all compilers support C99, and of those that do not all of them
conform to 100% of the requirements. The layout of structs and unions
is an ABI issue, and it's quite possible that there are systems that
can't afford to break the ABI for compatibility reasons.

Martin

> 
>   As discussed in 6.2.5, a structure is a type consisting
>   of a sequence of members, whose storage is allocated in
>   an ordered sequence, and a union is a type consisting
>   of a sequence of members whose storage overlap.
> 
> And (6.7.2.1 p14)
> 
>   The size of a union is sufficient to contain the largest
>   of its members. The value of at most one of the members
>   can be stored in a union object at any time. A pointer
>   to a union object, suitably converted, points to each of
>   its members, and vise versa.
> 
> It also voilates C++03 (expr.rel p2)
> 
>   If two pointers point to data members of the same union
>   object, they compare equal (after conversion to void*,
>   if necessary).
> 
> Even so, the last paragraph of "Rules for mapping one pair" says
> 
>   The pair is now a unit of fixed length and alignment
>   requirement, its length is the sum of the two lengths
>   plus padding, and its alignment requirement is the
>   higher of the two alignment requirements (if they
>   differ).
> 
> So the alignment would still be correct as the alignment requirement is
> weakest (smallest) for char types, so the alignment that would be used
> would be the alignment of the other type.
> 
> Please correct me if I'm misinterpreting any of this.
> 
> Travis
> 
>> Also, strictly speaking, names of data members should have
>> the _C_ prefix (double underscores are used for locals and
>> function parameters).
> 
> Agreed. I will fix.
> 
>> Martin
>>