> 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. Are BMessage one of those? this would be interesting to me if nothing else :) are these documented somewhere? > 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 ? > > -- MVH Fredrik Modéen