stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Date Mon, 24 Mar 2008 21:41:25 GMT
The two versions of aCC are very different (based on a different
C++ front ends). Each also runs on a different OS and hardware.
I think significant differences are to be expected. That doesn't
mean that there isn't a problem in our aCC 6.16 configuration,
but neither does it imply there is one.

Eric Lemings wrote:
>  
> In regards to STDCXX-709, note that there are no config differences
> in the delete operators, only the new operators.

These should be benign and unrelated to STDCXX-709.

FWIW, if you still suspect a mismatch between the allocation and
deallocation functions called from the tests I would suggest to
try to create a small test case reproducing it. I.e., create an
archive lib that allocates memory using the new expression and
a program that replaces operators new and delete, links with the
library and attempts to deallocate the memory allocated by the
library. See if the right operators are being called.

Martin

> 
> Brad.
> 
>> -----Original Message-----
>> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com] 
>> Sent: Monday, March 24, 2008 3:21 PM
>> To: dev@stdcxx.apache.org
>> Subject: RE: [STDCXX-709] ContainerData ctor and 
>> UserClass::from_char()
>>
>>  
>> I was just comparing the configuration differences for these
>> two platforms:
>>
>> HP-UX B.11.21/HP aCC 3.73
>> HP-UX B.11.31/HP aCC 6.16
>>
>> See http://people.apache.org/~elemings/diff.out.
>>
>> There seems to be way to many configuation differences.  I think
>> we may have a much more serious problem on HP-UX ia64.
>>
>> Brad.
>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of 
>> Martin Sebor
>>> Sent: Friday, March 21, 2008 5:10 PM
>>> To: dev@stdcxx.apache.org
>>> Subject: Re: [STDCXX-709] ContainerData ctor and 
>>> UserClass::from_char()
>>>
>>> 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
>>>
> 


Mime
View raw message