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
 72.14.204.230 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=DVfP1/z9GudJOm91CZQszZK9p/KE6tz35m+vPdO75OOPvKaj3oZtG1uI7KXnBIWJfV2JUBiaaDLkigfKiew4xdmKFyq0BmsHV/uFIG7ZQeLQFIwXqpMSiH5qRlVglbepIajmfMDAmT6LC3KNaNSqOmKiaOBG7Gq6FKBy7Qg5BZM=
Message-ID: <47E44038.5090404@roguewave.com>
Date: Fri, 21 Mar 2008 17:09:44 -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>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A368A@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: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Friday, March 21, 2008 3:32 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: [STDCXX-709] ContainerData ctor and 
>> UserClass::from_char()
>>
> ...
>> So you think there's a mismatch between the allocation function
>> invoked in value.cpp and the deallocation function called in the
>> header? Why would that be? IIUC, tests that replace operator new
>> and operator delete (such as 23.list.assign) replace it for the
>> whole process. If there's a mismatch, it can only be because
>> the operators aren't replaced consistently. Making sure this
>> replacement happens across the whole process, including any
>> libraries, is the responsibility of the C++ runtime (i.e.,
>> the compiler). If your analysis is correct, the C++ runtime
>> on IPF would have to be buggy.
>>
>> Or did I misunderstand what you were trying to say?
> 
> Sounds about right.
> 
> I just noticed there's a runtime link error in the config test
> OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms.  May be the
> culprit.
> 
> [user@host]$ ./include/OPERATOR_NEW_ARRAY_PLACEMENT
> /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
> module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
> Killed

That's a check for placement new in the runtime library. I don't
think that has any bearing on the replaceability of operator new.

I.e., the first one is not replaceable:

     void* operator new(size_t, void*) throw();
     void* operator new[](size_t, void*) throw();

while the second one is:

     void* operator(size_t) throw (bad_alloc);
     void* operator[](size_t) throw (bad_alloc);

The first form is usually defined inline in <new>, like so:

     inline void* operator new(size_t, void *ptr) throw() {
         return ptr;
     }

and so it's not defined in the runtime library. That's why I assume
the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares the operator
and calls it without providing a definition to see if one exists in
the runtime. Unless the test finds one we need to provide our own
definition in our <new>. Otherwise we just declare it.

Martin