http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #8 from Eric Blake <ericb at gcc dot gnu.org> 2012-04-25 19:31:59 UTC --- I hit this again today, and I'm still upset that gcc is doing such a poor job with (not) using this attribute as a way to improve code quality via decent warnings. Basically, libvirt had an issue where we accidentally misused the nonnull attribute marker; we had added the marker in a header file, then later changed the C file to work with a NULL argument but without updating the header file to match: https://bugzilla.redhat.com/show_bug.cgi?id=815270 The calling code managed to pass in a NULL pointer to a parameter based on the semantics we saw in the .c file, but the NULL check in our function in question was "helpfully" elided by gcc since the attribute was still present, all without ever warning us that we were losing the NULL check. As a result, the code misbehaved when it dereferenced NULL. If gcc is smart enough to elide code based on the attribute, it should be smart enough to issue a warning that we have dead code, and the only reason the code is assumed to be dead is because of a suspicious attribute. Had we had the warning, we would have known to either remove our dead NULL check, or to fix the header to no longer have the (now-inappropriate) attribute. In other words, with a header like: void foo(void *bar) __attribute__((nonnull(1))); and a C file like: void foo(void *bar) { if (!bar) abort(); } Even if you decide that you are unable to warn about a call to foo(var) because the only way to analyze that var might be NULL is in the middle end but the warning is only emitted by the front end, AT LEAST you could have warned that the 'if (!bar)' conditional is assumed to be dead code based on the attribute placed on var.
