[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