In regards to STDCXX-709, note that there are no config differences in the delete operators, only the new operators.
Brad. > -----Original Message----- > From: Eric Lemings [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2008 3:21 PM > To: [email protected] > 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:[EMAIL PROTECTED] On Behalf Of > Martin Sebor > > Sent: Friday, March 21, 2008 5:10 PM > > To: [email protected] > > Subject: Re: [STDCXX-709] ContainerData ctor and > > UserClass::from_char() > > > > Eric Lemings wrote: > > > > > > > > >> -----Original Message----- > > >> From: Martin Sebor [mailto:[EMAIL PROTECTED] > > >> Sent: Friday, March 21, 2008 3:32 PM > > >> To: [email protected] > > >> 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. > > > > > > [EMAIL PROTECTED] ./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 > > >
