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

[ori--- via TUHS]

Quoth Dan Cross <crossd at gmail.com>:
> 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.
>

Yes, it's certainly possible for people to sabotage the usefulness
of a well placed abort. This is something I find frustrating when
debugging, because even the best stack traces lack a great deal of
information.