GNUTLS_ASSERT macro

[Jeffrey Walton]

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.

In fact, it appears others would find asserts and "self debugging
code" useful: "main: TLS init def ctx failed: -1",
http://www.mail-archive.com/help-gnutls@gnu.org/msg01999.html.
Fredrik's comment:

    I guess my only option now is to instrument that part with
    debug information to see what return -1 triggers the error.
    .... Or can I turn on some gnutls flag that prints debug
    information ?

Frederik is asking for an assert to find the point of first failure so
he does not have to waste time under the debugger.

=====

The use of gnutls_assert() is somewhat unconventional. Typically one
asserts as follows:
ret = some_function(...);
assert(ret == 0);
if(ret != 0)
    ....

But the project is using its assert as follows:
ret = some_function(...);
if(ret != 0)
{
    gnutls_assert(ret == 0);
    ....
}

Trying to use gnutls_assert conventionally results in a compile error.

=====

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.

Inspecting gnutls_errors.h reveals a very unconventional definition:

#ifdef __FILE__
# ifdef __LINE__
#  define gnutls_assert() _gnutls_debug_log( "ASSERT: %s:%d\n",
__FILE__,__LINE__);
# else
#  define gnutls_assert()
# endif
#else /* __FILE__ not defined */
# define gnutls_assert()
#endif

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].

=====

According to the Open Group Base Specifications [1], "assert() shall
write information about the particular call that failed on stderr and
shall call abort()."

I've never liked the behavior, so I install my own SIG_TRAP handler.
It works great on Linux (Debian, Fedora, Ubuntu), Mac OS X, and
iPhone. If a debugger is attached, the debugger snaps. If no debugger
is attached, the program continues normally after writing a message to
stderr.

The project is welcome to the code if interested. I'll place it in
public domain, so there will be absolutely no licensing issues.

=====

The 'make check' target should be assert agnostic. I've already
experienced some automake awkwardness because the tests take the same
settings as the libraries. My experience has been that building both
libraries and tests with asserts spuriously pops asserts on negative
tests. The spurious asserts are a total distraction.

What I really wanted was a way to build one particular test, so I
could get the one test under gdb. But automake and friends has a
penchant for building a group of applications, and then running the
group, and then building another group, etc.

Missing the ability to build one test with desired settings, I've
found a desire to disgorge the libraries' CFLAGS from the tests'
CFLAGS. As far as I can tell, thats not possible either.

Jeff

[1] http://www.opengroup.org/onlinepubs/009695399/functions/assert.html