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

[Bakul Shah via COFF]

> On Nov 9, 2025, at 11:45 PM, Dan Cross via COFF <coff at tuhs.org> wrote:
> 
> On Sun, Nov 9, 2025 at 10:22 PM <ori at eigenstate.org> wrote:
>> Quoth Dan Cross <crossd at gmail.com>:
>>> Post mortem analysis is undeniably useful. But I maintain that it is
>>> _mostly_ orthogonal to `assert`.
>> 
>> What are you doing with the printed values of assert (or the
>> stack trace), other than post mortem analysis?
> 
> That's reductive.  Surely there is a qualitative difference between
> reading an error message and invoking a debugger, no?  And as I said,
> there are instances where you `assert` and no core file (or broken
> process) to debug is produced.
> 
>        - Dan C.
> 
> (And of course I must acknowledge that I did misread your earlier
> statement about stack traces being at times insufficient.)

What I would like is to see on assert() failure is for the system
to invoke a debugger, provided matching source can be found. But
this requires compilers/linkers to *not* throw away information[1].

If a decent protocol is defined and appropriate access permissions
are obtained, in theory a failure at a customer site can invoke
the debugger at the developer site[2]. Then instead of an autopsy
one can do a biopsy and may be even temporarily "cure" the patient!

This can be useful when a system (or test) fails after many hours.

[1] Would be nice to see C/C++/etc. compiled language tools to
catch up to Lisp systems of the last century!

[2] Dealing with leakage of customer/personal info is a separate
issue but must be dealt with in any remote debugging protocol.