Re: [Gluster-devel] Query regarding GF_ASSERT macro

[Harshavardhana]

> assert() macro also behaves in the same manner. It is an usual practice to
> have assert() be a NOOP in production builds. assert()'s normal usage is to
> assert that the expression is TRUE and it _should_ not be considered as a
> replacement for NULL pointer checks. If we want to avoid NULL pointer
> dereferences, it is a good idea to handle such scenarios and bail out
> gracefully.
>>
>>
>> A typical example of this scenario is :
>>
>>
>> GF_ASSERT (shandle);
>> GF_ASSERT (shandle->path);
>>
>> My question is why don't we abort in case of production build? Any
>> specific reason?
>

This question has come before and many times clang checks and other
debugging tools "warn" about NULL deference issues after this macro
has been invoked.

But from what i gather GF_ASSERT in GlusterFS context is much like
BUG_ON for Linux kernel - assert is only necessary during debugging -
a backtrace is valid in case of a crash for production where we get
something called gluster dump synonymous with 'Kernel dump'

I guess we can have much more broader discussion on its implications,
FWIW it was necessary from GlusterFS context to not have "assert()"
with in that macro.