[cfe-dev] Possible trivial correction to test/Analysis/malloc-annotations.c

[Andrew McGregor]

Having actually annotated a large codebase (since I wrote the annotations
in the first place)... yes, it is a lot of work.  In our case, months of
work on 77 MLoC, but the result was several thousand potential crash bugs
resolved and a measurable improvement in support workload for the product.

I was going to work on annotation deduction, so the analyser could work out
if there was a missing annotation and tell you what it should be (with a
fixit, of course), but having changed jobs I no longer have time to work on
that.  It is feasible, however.


On Fri, Apr 19, 2013 at 6:34 AM, <bruce.r.stephens at gmail.com> wrote:

> Anna Zaks <ganna-2kanFRK1NckAvxtiuMwx3w at public.gmane.org> writes:
>
> > Note, that the checker that uses the annotation (MallocOptimistic) is
> > in alpha state and probably needs a major redesign and
> > productization. The functionality that is there now has not been
> > tested much. Currently, that checker assumes that every function which
> > might free memory will be annotated. This applies to functions that
> > free memory indirectly, by calling another function. This greatly
> > limits applicability of the checker.
> >
> > We are thinking of augmenting the MallocPessimistic, which assumes
> > that any unknown function can free memory, with annotations on
> > functions which the user has more info about, instead of reviving the
> > MallocOptimistic checker.
>
> Agreed, yes. The default malloc checker (MallocPessimistic, IIUC) works
> well. Not perfect, of course, but very useful.
>
> By the looks of it the annotated malloc checker would require
> unrealistic amounts of annotation to bring the false positives down
> enough for it to be useful at least in the codebase I'm working
> on. Starting from something similar to MallocPessimistic ought to
> produce something useful, much as I like (in principle) the idea of
> annotating functions with ownership information.
>
> [...]
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130427/8269a770/attachment.html>