GNUTLS_ASSERT macro

[Jeffrey Walton]

On Fri, Nov 26, 2010 at 12:19 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Fri, Nov 26, 2010 at 4:08 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>> Hi All,
>> A properly asserted program expedites finding the point of first
>> failure in a program or library. I believe the current GnuTLS assert
>> could be improved.
>
> gnutls_assert() is not related to the use of assert(). The name might
> be confusing, but it's already there. We use gnutls_assert() to get an
> easy backtrace of a program that fails without going through the debugger.
>
> There is run-time functionality to enable assertions and print information
> on them.
>
>> Typically, and application or library is built with either a "debug"
>> configuration, or a "release" configuration. The current assert is
>> gnutls_assert(), which does nothing when DEBUG is defined.
>
> It's not related to how assert() works.
>
>> GnuTLS should probably honor the intent of standard assert() and
>> provide equivalent behavior: if NDEBUG is defined, asserts are not
>> compiled into the program code. Otherwise, asserts are compiled into
>> the program code [1].
>
> No. The original assert() is very dangerous,
How so?

> ... and pretty useless to me.
OK. To each their own.

> Projects that need assertions why wouldn't they use them
> in production code?
Asserts are a development tool. Hence the reason the standard states
"[defining NDEBUG] shall stop assertions from being compiled into the
program."

> The cost of the instructions of the "if" is pretty low to even
> consider it.
Agreed. I don't worry about 3 cycles, and with modern branch
prediction algorithms, the hit rate is well over 90%.

Jeff