On 06/12/2016 02:45 PM, Guillaume Munch wrote: > Le 12/06/2016 19:39, Richard Heck a écrit : >> On 06/12/2016 09:17 AM, Jean-Marc Lasgouttes wrote: >>> Le 12/06/2016 15:05, Georg Baum a écrit : >>>> If others want to join the effort please keep in mind that the goal >>>> is not >>>> to get zero coverity errors, but to fix dangerous code. So if you >>>> do not >>>> understand an issue 100%, or understand it but do not know how to fix >>>> it, >>>> please keep it open. I did that for some of the errors reported by >>>> cppcheck, >>>> for example there is a NULL-pointer dereference at the end of >>>> copySelectionHelper() (which works in practice since it is only used >>>> to set >>>> a reference which is usually implemented as a pointer), but fixing >>>> this >>>> properly would be a big refactoring. >>> >>> Coverity allows to annotate false positives, which is a nice thing to >>> do. At least we get to see that it is marked and may disagree. >> >> Yes, I marked quite a few of these. Coverity can't always tell, for >> example, whether a pointer may be null. We may have our own reasons to >> know it can't be if, say, we are in an LFUN that can only be issued when >> we have a document view. But these are all worth checking, it seems to >> me, and annotating, if only so that no-one else will have to check. >> > > Interesting. What comment should I add to a function declaration to > inform that a returned pointer cannot be null, by design?
I don't think we have a definite policy, but it would be a good sort of comment to have. Coverity seems to want the comment right before the code it complains about, though, so I'm not sure this can be done ahead of time. Richard
