[TUHS] To NDEBUG or not to NDEBUG, that is the question

Clem Cole via TUHS tuhs at tuhs.org
Fri Oct 17 21:56:15 AEST 2025


FWIW:  assertions are like a PFD (a.k.a. Personal floation device or life
preserver).  Going with a PFD is never a good idea, particularly if you are
in open waters, as you never know when you could accidentally get washed
overboard.

Sent from a handheld expect more typos than usual


On Fri, Oct 17, 2025 at 7:42 AM Aharon Robbins via TUHS <tuhs at tuhs.org>
wrote:

> Hello All.
>
> A bit off-topic, perhaps, but thoughts from this crowd would be welcome.
>
> I just finished tracking down a bug in gawk that was only noticed
> because the Windows port is built without -DNEBUG, causing assertions
> (via assert(3)) to be included in the code.  The regular *nix build
> defines NDEBUG, so that assertions are not included in the regular,
> "production" build.
>
> Now, I can understand why assert() and NDEBUG work the way they do.
> Particularly on the small PDP-11s on which C and Unix were developed,
> it made sense to have a way to remove assertions from code that would
> be installed for all users.
>
> However, I'm starting to wonder.  Are my habits from yesteryear (defining
> NDEBUG by default) getting in the way of my being able (or users being
> able) to find bugs and report them?  Should I remove the defining of
> NDEBUG from the default build?  In particular, given the many orders of
> magnitude increase in CPU and memory of modern systems, is it likely
> that assertions won't really affect performance all that much?
>
> I'm starting to think that the answer is yes, it's time to remove
> NDEBUG.  But I'm curious what the experienced developers here
> might think.
>
> Much thanks,
>
> Arnold
>


More information about the TUHS mailing list