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

[Clem Cole via TUHS]

Going >>without<< a PFD — dyslexia-R-me

Sent from a handheld expect more typos than usual


On Fri, Oct 17, 2025 at 7:56 AM Clem Cole <clemc at ccc.com> wrote:

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