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

[Dan Cross via TUHS]

On Fri, Nov 7, 2025 at 1:54 PM Ori Bernstein <ori at eigenstate.org> wrote:
> On Fri, 17 Oct 2025 08:22:23 -0400, Dan Cross via TUHS <tuhs at tuhs.org> wrote:
>
> > One must question whether `assert` is the right thing or not, though;
> > as an interface, it's pretty limited: a thing can either be true or
> > not, but any surrounding information is not preserved;
>
> This is untrue -- with core dumps enabled, surrounding information is
> preserved better than most other options.

Apples and oranges.  Presumably you're referring to a post-mortem
analysis pointing a debugger at a core file and binary, but that vs
the printed output from a failed `assert` is sufficiently dissimilar
as to be specious.  Furthermore, there's no guarantee that a failed
`assert` will result in a core file being produced; production of core
dumps can be disabled, but even if not, a process can catch `SIGABRT`
and `longjmp` out of the handler; POSIX and C both explicitly allow
for that.

There is a reason people invent `ASSERT3x` macros for x in {U,P,I},
etc, and it's not just for kicks. And besides, as Arnold pointed out,
it _can_ be done with `assert`: it's just ugly and painful. And of
course, one can always use an explicit conditional, print whatever one
likes, and call `abort()` directly if one wants (possibly resetting
the signal handler to the default before-hand). You may still not get
a core dump, but at least you can print whatever context you like.

        - Dan C.