[haiku-development] Re: object on the hype, using it as parameter and then use delete

  • From: "Stefano Ceccherini" <stefano.ceccherini@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 12 Sep 2008 15:33:57 +0200

2008/9/12 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>
> On 2008-09-12 at 14:48:49 [+0200], Stefano Ceccherini
> <stefano.ceccherini@xxxxxxxxx> wrote:
>> 2008/9/12 Michael Lotz <mmlr@xxxxxxxx>:
>>
>> > You make the same assumption that new cannot fail in r27448 which I find
>> > a bad
>> > idea. You could say that it is true that new cannot return NULL, since it
>> > should actually throw an error and not return NULL. However this is not a
>> > reason to strip the NULL checks, but to make new into new(std::nothrow)
>> > which
>> > actually returns NULL on a failed allocation (which can always happen). I
>> > thought we had the general consensus that we use new(std::nothrow) and
>> > always
>> > check the result, but I'm not sure how the other see it.
>>
>> Yep I am for the nothrow + NULL check, too.
>
> +1
>
>> BTW I think that it should be clear that the Coverity reports aren't
>> bulletproof: IOW: one should do a "manual" analysis before changing
>> code based on the reports.
>
> Absolutely! I believe most of the kernel "defects" I have checked so far
> refer to correct code. E.g. the "double deletion" checker seems to be
> totally lost when analyzing code using reference counting. Maybe we should
> collect and document these kinds of patterns somewhere.

Yes, I noticed that too.
Coverity also can't know that there are some classes which autodeletes
themselves on quit.
For example, BAlert, BWindow, etc.
Some other like BMediaTrack should not be deleted by the user either.

> If I understand it correctly, we can also have a mailing list where the
> Coverity tool and its problems can be discussed and which is also read by
> the Coverity people.

Interesting, so we should for example point out the things I just mentioned ?

Other related posts: