[haiku-development] Re: possible bad usage of "new" in haiku

  • From: romain.haiku@xxxxxxxxxxx
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 3 Nov 2008 13:57:31 +0100 (CET)

> > > > Maybe we should make all haiku classes inherit from a common
> > > > class that
> That's not possible, at least not for R1, because it would break the
> whole API compatibility with BeOS.

I thought about this, but hoped there may be a way to do this without
breaking binary compatibility.

> > > > would just overload new with something like that:
> Some applications actually use exceptions (like Pe...).

ok, so forcing nothrow new is maybe not a good idea then. This would
prevent such software from trapping the allocation error exception.

> > > As inherited from the Be API, our API is indeed not supposed to
> > > throw any
> > > exceptions. Therefore, all API implementations are bound to use new
> > > (std::nothrow) all the time.
> > > If you detect any usage of "new" without std::nothrow, please open
> > > a bug
> > > report for this or supply patches that fixes those instances.
> > If you spot usage of new without std::nothrow in applications and
> > preflets,
> > I would not report all those, just within the kits. Otherwise we
> > would be
> Well, for self-contained code, maybe it's possible to use a trick with
> "using std::nothrow::new" at the top of the file for simplicity ? Would
> still need a lot of NULL checks I suppose.

In the interface kit for example, there are already several calls to new
without std::nothrow: for a BMessage (is it ok with its custom
allocator?), for a TAlertView in the instanciate method. Also in
Button.cpp the instantiate method does not use nothrow.
The instantiate method can also be problematic because it can be called
from "instantiate_object", which is not supposed to raise an exception,
but return NULL.

> > overwelmed with the reports. One more question though: What about
> > "new
> > BMessage"? AFAIU, BMessage has a custom allocator? Can nothrow be
> > ommited
> > there?
> Oh I didn't notice that one...

on a simple test class overloading operator new with a "return NULL", I
get the following warning from gcc 4.2.3:
"attention: operator new must not return NULL unless it is declared throw()"

The warning may not appear on the BMessag class, but the fact is that new
can probably still return a NULL pointer here.

> Hmm I suppose nothrow will change the signature and break the ABI...


Other related posts: