[cfe-dev] GSoC 2012: Static Function Blacklisting

Mark McCurry mark.d.mccurry at gmail.com
Fri Mar 30 07:04:18 PDT 2012


>> Can the annotations/attributes in clang be extended in this manner
>> (ignoring example syntax)?
> You can add any attributes you like but to get them up stream would be hard as adding attributes is adding language extension and Clang definitely doesn't want to include arbitrary domain specific attributes. If you take a look at the attribute definition file, the attributes there are either from standard, or Clang built in, or already available in GCC (like thread safe annotations).
> One idea of extending attribute system is to take a look at the Clang "annotate" attribute which you can embedded arbitrary literals so technically you can get your own annotation DSL inside the "annotate" attribute.

As of so far my searching has only resulted in finding the standard
set of __attribute__() declarations defined in clang.
ie
http://clang-analyzer.llvm.org/annotations.html
http://clang.llvm.org/docs/LanguageExtensions.html

Are these the annotations you are referring to or have I overlooked something?
ie is there an __attribute__(annotate()) ?

>
>> Can attributes be assigned to functions without altering the source
>> (the library case)?
> It is possible and what we did in our tool is to redeclare the library / 3rd party functions with annotated attributes, and in Clang Sema, merge the attributes into function types.
>
>> Does this sound like a good/feasable summer of code project?
> It should be very useful as there are many low-hanging fruits out there that could be reached by this.
> A more ambitious goal would be to extend Clang by providing a framework to encode the attributes and the "rules" (e.g. a white/black call list of a function) so clang users could add their own domain specific checks without reinvent the wheel again.

I am not too sure how ambitious to be with the scope of this project,
but I certainly do intend to make it an easily extended system, such
that it will apply to a variety of use cases.

--Mark




More information about the cfe-dev mailing list