On Fri, Jan 3, 2014 at 1:03 AM, Xavier Hernandez <address@hidden> wrote:
El 03/01/14 07:02, Harshavardhana ha escrit:
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'
Probably it's only a matter of semantics, but I think that an assert should
be something that must be true under any circumstance. Even more, many times
the program will crash soon if an assert fails and it's not handled (i.e.
program aborted). If the program does not crash, something may get corrupted
which is worse. If some condition can be false under some rare circumstances
or it's possible to recover from a failed test, it would be better to use
GF_VALIDATE_xxx macros.
I agree that on production builds, where (most) bugs have been killed, these
macros could be a NOOP for performance reasons, however GF_ASSERT() checks
the condition even in production builds. For this reason I think it would be
better to force the program to abort even in production, or the macro be
completely converted to a NOOP.
There were similar discussions in the past there wasn't any clear
understanding of what
should be done here. I guess GF_ASSERT should be replaced with GF_VALIDATE_xxx
macros perhaps for all functions which need input validation (or which
function doesn't? :-))