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

[segaloco via COFF]

On Friday, November 7th, 2025 at 17:48, Dan Cross via COFF <coff at tuhs.org> wrote:

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

In my mind, assert implies some knowledge of a failure condition
to look for.  Post mortem I usually find myself doing is to find
a failure condition that I am not aware of.  Once found, an
assertion can be made as a regression test against the now-known
failure condition, which can be omitted via NDEBUG.  That feels
clean to me at least.

- Matt G.