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
 209.85.200.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=mVeO5p/6VimGmeIFllmPjEgKqXzDr9UcinAcZCHdup4V64oF9SfYCvT6i9YhLelS2FeW21y9JMmvgFykL2xFUSl7zzVvWWhQiET9irlJj0yTmZ+zDc5meK5/fSNQpoOPHt/qOPN8m6sCkQDlOQNKuHZYkHY7IebHaj+yQScoJCE=
Message-ID: <47F057E7.4020206@roguewave.com>
Date: Sun, 30 Mar 2008 21:17:59 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3688@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3689@exchmail01.Blue.Roguewave.Com>
 <47E42941.8040704@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A368A@exchmail01.Blue.Roguewave.Com>
 <47E44038.5090404@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A368B@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A368C@exchmail01.Blue.Roguewave.Com>
 <47E82005.50006@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3694@exchmail01.Blue.Roguewave.Com>
 <47E9BBD7.4060606@roguewave.com> <47E9D7CD.9060003@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3698@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A369B@exchmail01.Blue.Roguewave.Com>
 <47EACBE8.7040204@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A36A3@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A36A4@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A36A4@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Eric Lemings 
>> Sent: Thursday, March 27, 2008 2:05 PM
>> To: 'dev@stdcxx.apache.org'
>> Subject: RE: [STDCXX-709] ContainerData ctor and 
>> UserClass::from_char()
>>
>>  
>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>>> Sent: Wednesday, March 26, 2008 4:19 PM
>>> To: dev@stdcxx.apache.org
>>> Subject: Re: [STDCXX-709] ContainerData ctor and 
>>> UserClass::from_char()
>>>
>> ...
>>> It seems pretty clear that somewhere between the call TO
>>> operator new and the return FROM the function the pointer
>>> gets bumped up by 8 on LP64 (and 4 on ILP32 according to
>>> your observation). The only thing in between these two
>>> steps is the call to the UserClass ctor. So unless the
>>> ctor manages to change its own this pointer we're looking
>>> as a compiler bug. Either way, we need a small, isolated
>>> test case to understand how to deal with it...
>>>
>>> Martin
>> The pointer is being adjusted before the constructor is
>> called.
>>
>> I was looking yesterday at GCC's implementation of the
>> C++ ABI __cxa_vec_new2() function.  There's a padding
>> argument that may be utilized in HP-UX aCC 6.x for some
>> unknown reason.
>>
>> Also, I thought the allocator in _rw_dispatch(), where
>> the ContainerTestCaseData object is being constructed,
>> could play some role in all this but looks like its
>> only used in the test function.
>>
>> Brad.
> 
> Does HP-UX IPF have any sort of memory alignment restrictions
> that anyone is aware of?

Usually, the preferred (required on some systems) alignment
of a built-in type corresponds to the type's size. According
to HP, int and float are 4-byte aligned, and doubles are 8
byte aligned:

http://www.docs.hp.com/en/1552/comp_run.html#RN.CVT.NN100

AFAICT, malloc() returns pointers aligned on the 8-byte
boundary.

Martin