The secp256k1.o object should be built with NDEBUG about secp256k1 HOT 5 CLOSED

This pretty much comes down to maintainer preference. Most packages don't enable NDEBUG, rather they let the user handle it via ./configure CPPFLAGS=-DNDEBUG.
In reality, it's usually the distros that handle the above.

In this case, bench hard-coding NDEBUG makes sense, since it's not user-facing. One could possibly argue the same for the tests.

Another option is something like --enable-debug, on by default.

Preference?

from secp256k1.

I'd argue that a library whose primary purpose is efficiency can reasonably be expected to not build debug code by default, but maybe that's uncommon practice.

Of course, we could equally just replace assert() by a macro that only has an effect when VERIFY is defined? :)

from secp256k1.

We should probably not use assert.h. We should use local debugging macros instead. It would resolve that issue nicely...

from secp256k1.

@sipa: I would agree with that. Agree with @gmaxwell as well.

Since assert has performance implications, and is more complicated than simply "die here when debugging, and I guarantee we'll never get here in production", hard-coded -DNDEBUG and a custom secp_assert() with those simple semantics makes sense in this case.

from secp256k1.

Closing; #54 switched everything to our own CHECK/VERIFY_CHECK/DEBUG_CHECK macros. NDEBUG now only switches the public API input verification off.

from secp256k1.