[cfe-dev] Ownership attribute for malloc etc. checking

[Andrew McGregor]

On Tue, Jun 29, 2010 at 1:27 PM, Ted Kremenek <kremenek at apple.com> wrote:

>
> On Jun 28, 2010, at 6:16 PM, Andrew McGregor wrote:
>
> > Hmm, but which is cleaner and clearer... have the checker know that
> arguments might be attributed as well, or have the parser push attributes
> from arguments onto the function?  The latter is probably less code, but
> might be rather obscure.  On the other hand, that whole attribute parser is
> pretty obscure, and is full of 'fixme's saying it deserves redesigned.
> >
>
>
> I don't think we want to duplicate attributes; attributes on the
> ParmVarDecls should only be on the ParmVarDecls, unless of course we want to
> incorporate the the attributes into the function's type.  The AST should
> have high fidelity to the actual source code.
>
> That said, I don't think the checker should be in the business of having to
> reason about how the function was annotated.  The checker just cares about
> the semantics, while it's up to the parser and the attributes to handle the
> syntax.
>
> One possible solution is to provide a static function(s) to OwnershipAttr
> et al that allows one to query a FunctionDecl for the relevant annotations.
>  Then the checker just cares if a parameter is annotated, but it doesn't
> care how it was written.


So, thinking about this led me to this idea:

These attributes actually have minimal differences so far as the checker is
concerned.  So how about there being only one attribute object  type,
probably an OwnershipAttr, with an enum kind embedded in it, that can be
applied to an argument.  Each one would apply to just one argument or the
return value, but may have several arguments (the so far unimplemented
calloc case will need this, as will pointer-to-pointer malloc).  The parser
would have to construct two attribute objects for
__attribute((ownership_holds, 1, 2)).  That way the dispatch can be a case
statement on the enum rather than the current mess of casts and tests.  This
would also save some of the methods from being templates, which I think
would be unnecessary complexity.

Or, again in order to reduce the duplication, I could make templates of some
of the methods and use the type to represent the attribute kind the same way
as I have so far.  Disadvantage: this is probably going to bloat.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100629/c6ac1441/attachment.html>