On 17.2.2016 18:43, Jakub Jelinek wrote: > On Wed, Feb 17, 2016 at 05:30:27PM +0000, Daniel P. Berrange wrote: >> Instead of using __attribute__((nonnull)) directly in the code, define a >> macro for it. When compiling normal builds with gcc, make the macro >> expand to nothing, but when compiling with coverity or other static analysis >> tools make it expand normally. > > Well, nonnull attribute is not primarily a debugging aid, but an > optimization hint, which allows the compiler to optimize, sometimes > significantly, the code that gives the compiler the additional information > it can't figure itself otherwise. > So while it could make sense to disable it in debug builds if you want > your assertions to work, for production builds built without assertions > it is really unnecessary pessimization of the code if you don't define it. > >> * still requiring correct gcc syntax when it is turned off. See also >> * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 */ > > Funny you mention this PR, because the new warning is one of the > warnings requested in that PR. And now some people are complaining that the > warning got implemented.
The thing is that some developers (e.g. me and ISC :-)) do not think that assert() should be used only in debug builds. E.g. BIND itself is written in "Design by contract" spirit and asserts are used all over the place to make sure that code which does not behave as intended is killed as soon as possible (and thus prevented from doing collateral damage). Call it defensive programming if you wish. In past 15 years, this allowed BIND 9 to avoid exploitable code execution bugs [1] and turned most of them into mere DoS. You can compare this with BIND 4 and BIND 8 which were famous for this kind of the bugs (and didn't have asserts() all over the place). BTW libresolv in today's glibc was taken from BIND 8 :-) Quick grep shows 10497 asserts in BIND itself, so it is not realistic to say 'go and rewrite it from scratch', sorry. Apparently BIND is using -fno-delete-null-pointer-checks from GCC 4.9 times. Anyway, thank you for your input, I will find my way how to hack around it. [1] http://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64 -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
