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

[Dan Cross via TUHS]

On Fri, Nov 7, 2025 at 8:40 PM <ori at eigenstate.org> wrote:
> 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.

[This is getting into COFF territory; TUHS to Bcc:]

Not just users, but administrators, system policy and so forth;
consider an `abort` in a setuid program. And of course, stack traces
can be generated without the use of `abort()` or production of a core
file; there are pre-canned libraries for pretty much all mainstream
systems for doing that these days.

Post mortem analysis is undeniably useful. But I maintain that it is
_mostly_ orthogonal to `assert`.

        - Dan C.