]> xenbits.xensource.com Git - libvirt.git/commit
build: make ATTRIBUTE_NONNULL() a NOP unless STATIC_ANALYSIS is on
authorLaine Stump <laine@laine.org>
Wed, 25 Apr 2012 20:10:01 +0000 (16:10 -0400)
committerLaine Stump <laine@laine.org>
Tue, 1 May 2012 20:48:03 +0000 (16:48 -0400)
commiteefb881d4683d50882b43e5b28b0e94657cd0c9c
tree48c3ed5b1fb94c5a4df2d365f1593c67917f9133
parent07cf96ecc7b0933c67febb1c5bd50fc0bbeba263
build: make ATTRIBUTE_NONNULL() a NOP unless STATIC_ANALYSIS is on

The ATTRIBUTE_NONNULL(m) macro normally resolves to the gcc builtin
__attribute__((__nonnull__(m))). The effect of this in gcc is
unfortunately only to make gcc believe that "m" can never possibly be
NULL, *not* to add in any checks to guarantee that it isn't ever NULL
(i.e. it is an optimization aid, *not* something to verify code
correctness.) - see the following gcc bug report for more details:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308

Static source analyzers such as clang and coverity apparently can use
ATTRIBUTE_NONNULL(), though, to detect dead code (in the case that the
arg really is guaranteed non-NULL), as well as situations where an
obviously NULL arg is given to the function.

https://bugzilla.redhat.com/show_bug.cgi?id=815270 is a good example
of a bug caused by erroneous application of ATTRIBUTE_NONNULL().
Several people spent a long time staring at this code and not finding
the problem, because the problem wasn't in the function itself, but in
the prototype that specified ATTRIBUTE_NONNULL() for an arg that
actually *wasn't* always non-NULL, and caused a segv when dereferenced
(even though the code that dereferenced the pointer was inside an if()
that checked for a NULL pointer, that code was optimized out by gcc).

There may be some very small gain to be had from the optimizations
that can be inferred from ATTRIBUTE_NONNULL(), but it seems safer to
err on the side of generating code that behaves as expected, while
turning on the attribute for static analyzers.
src/internal.h