------- Comment #1 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10
07:48 -------
This is actually a lot more serious than just a documentation issue (I've
changed it from a doc issue to a gcc issue) in that the use of this annotation
by the optimizer will break correctly-functioning code by silently removing any
checks for NULL pointers. To summarise the original issue:
There are cases where no warning about use of a NULL pointer is issued because
the analysis required to reveal this would have to be done by the back-end, but
the back-end optimiser still changes the code that it generates under the
assumption that the pointer is never null.
In other words use of this annotation to warn about NULL pointers results in
code that segfaults if the pointer ever does happen to be NULL, even though the
compiler doesn't (reliably) warn about use of a NULL pointer in the first
place. Because of this it's just too dangerous to use, if the compiler can't
reliably warn about use of NULL pointers then it shouldn't then use this
unreliable information to change the behaviour of generated code.
The problem is compounded by the way the attribute is used, for __unused__ the
attribute is placed in front of the variable that it affects but for
__nonnull__ it's necessary to tediously hand-count parameters and then provide
a list of index values for the attribute. When annotating a function with
several pointers, some of which can be null and some of which can't, it's very
easy to lose track and supply an off-by-one index, which gcc uses to remove
NULL pointer checks resulting in segfaults in apparently-correct code. Is
there any reason why __nonnull__ can't work the same way as __unused__?
--
pgut001 at cs dot auckland dot ac dot nz changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|minor |normal
Component|web |c
Summary|Documentation for the |Use of the 'nonnull'
|'nonnull' attribute is a bit|attribute breaks code
|misleading |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
