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

[Marc Donner via TUHS]

The answer on NDEBUG depends too much on how the debug machinery is
implemented and how it works.  If the debug machinery hangs out an
unsecured port to which anyone might send commands and from which it might
pull information, then you obviously do not want that in the production
system.

The old SLAMMER infestation relied on development and debugging artifacts
included in the early-2000s MSDE system.  Habitually production teams did
not strip these away when deploying production code, since debugging.

YMMV
=====
mindthegapdialogs.com <https://www.mindthegapdialogs.com>
north-fork.info <https://www.north-fork.info>


On Fri, Oct 17, 2025 at 7:50 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
>