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