------- 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