[cfe-dev] GSoC 2012: Static Function Blacklisting

[Mark McCurry]

> I agree with David that a blacklist approach is doomed to failure because of
> the opacity, in general, of function declarations. A whitelist... would just
> be a maintenance nightmare.

I personally think that (for externally referenced libraries)
whitelisting/blacklisting various functions could be a viable option.
Outside of maintaining some list, custom headers would need  which
IMHO would be more of a maintenance issue.
Attributes would be a good choice for in project code.
I may be misinterpreting what scope you are talking about for the
whitelist/blacklists though.


> On the other hand, for attributes, there is the possibility of specifying
> that attributes should appear on the first declaration of a function, and
> that subsequent declarations (and definitions) cannot *add* to the list
> (they may specify less).

The one issue with this would be external code (ie libraries), which
would either need an external method of declaring the properties or
the ability of adding one.
In what cases were you thinking specifying less properties would have
utility to developers? (briefness/backwards compatibility)

> You could perhaps put in place a "property" system:
> __attribute__((__property__("reentrant", "realtime")), which though an
> extension to Clang is perhaps sufficiently generic to warrant consideration
> (you would have to check with Douglas Gregor and Ted Kremenek at least). And
> specify that for this attribute, a subsequent declaration/definition cannot
> gain a property (it might be looser).

This is quite close to what I have intended, but I feel like it may
require some over-annotation (if all realtime functions must manually
get the assigned "realtime" property (syntax is great)).
I am fairly sure that it would be much less verbose if there was an
ability for the analyser to assume that a function has some property
by default until proved otherwise.

eg: if foo() has the realtime property and it calls bar(), then bar()
is assumed to be realtime until a contradiction is reached (ie bar()
calls a non-realtime function).

This could lead to the unmaintainable list of whitelists and
blacklists, but I would prefer to not force developers to annotate
their entire codebase for the static analysis to be effective.

> One thing to consider, however, is the difficulty to do so for template
> functions. This is, in essence, similar to `noexcept`, and the Standard
> specifies a form `noexcept(boolean-expression)` to allow expressing
> conditions on template functions/methods. This makes things a bit harder, no
> doubt.
>
> Perhaps that templated code should be kept out of the loop in your project,
> or at least, dependant annotations.

Templates are certainly a nasty case and while it would be nice to
account for that case, it is reasonable to let them fall into an
undefined case.

--Mark