incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Date Mon, 24 Mar 2008 21:27:13 GMT
 
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: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