On 2008-09-12 at 15:33:57 [+0200], Stefano Ceccherini <stefano.ceccherini@xxxxxxxxx> wrote: > 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 > ? Yep, I guess that would be interesting for the Coverity people to improve their tool. CU, Ingo