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

[Clem Cole via TUHS]

Cool.  One of the old ISVs we worked during my DEC days (I’ve forgotten
which) had an ASSERT3 macro with the value you had, what was expected and
an optional message. Then the fprintf then added __FILE__ and __LINE__ with
the message if added.

But it all comes back to accepting being washed overboard happens when you
least expect it and as you point out, added with careful placing, the
performance cost should be negligible.

Sent from a handheld expect more typos than usual


On Sun, Oct 19, 2025 at 3:12 AM Arnold Robbins via TUHS <tuhs at tuhs.org>
wrote:

> Dan Cross <crossd at gmail.com> 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; for example,
> > one often wants to assert whether two things are equal, but if they
> > are not, it's often very useful to know what the actual values are:
> > `assert` doesn't give you that.
>
> It can be done, it's just not pretty:
>
>         assert(answer == 42 ? true :
>                 fprintf(stderr, "answer = %d, expected 42\n", answer),
>                 fflush(stderr), false);
>
> Note the use of the comma operator.  The joys of Obfuscated C. :-)
>
> (I do get your main point.)
>
> Arnold
>