Eric Lemings wrote:
-----Original Message-----
From: Eric Lemings
Sent: Thursday, March 27, 2008 2:05 PM
To: '[email protected]'
Subject: RE: [STDCXX-709] ContainerData ctor and
UserClass::from_char()
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 4:19 PM
To: [email protected]
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
