> 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. _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
