On 19.2.2016 13:30, Jonathan Wakely wrote: > On 19/02/16 10:49 +0100, Petr Spacek wrote: >> 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. > > That's fine. Don't use attribute((nonnull)) then. > > It's illogical to promise the compiler that something will never, > ever, ever be null, but also check whether it's null. If you're not > 100% certain it can't be null, then you lied to the compiler. If you > are 100% certain it can't be null then the assert is redundant and can > be removed. > > If you're only 99.999% certain, and so the assert serves a useful > purpose, then don't make promises that you can't keep. > > If you just want to advise the compiler that something *probably* > won't be null, and tell it to optimize based on that assumption, then > you can use __builtin_expect() to provide that hint (although I > wouldn't actually recommend doing so). > > Don't make a promise when you mean to give a hint. This is nice in a theory but not in practice. You can give promises about state of your program you wish, but these promises can 100 % hold only for bug-free programs using bug-free libraries. Everything else is going to face real world where various bugs cause that various 'promises' will not hold. As I said above in the original question, the (nonnull) attribute is used to help static analyzers, not as optimization hint. #if defined (__GNUC__) and -fno-delete-null-pointer-checks will workaround it for me. Thank you for your input, guys. -- Petr Spacek @ Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
