[scc-dev] Re: Sorry for the delay

From: Roberto E. Vargas Caballero <k0ga_at_shike2.com>
Date: Thu, 2 Mar 2023 13:49:59 +0100


On Wed, Mar 01, 2023 at 06:30:30PM -0500, Tim Kelly wrote:
> Roberto E. Vargas Caballero wrote:
> I really don't understand the benefit of excluding information from the
> programmer and forcing them to reach for a debugger, any more than I
> understand making the programming read the man page to understand why a flag
> doesn't work. A minor bit of work from the developer saves the programmers
> quite a bit of time.

Abort() shouldn't happen due to a invalid flag combination. If you find a
case where it happens that is a bug. Abort() happens only when an unexpected
path happens and we have to stop as soon as possible. I usually don't use
debuggers neither, but I still think core files are useful and they are with
us since UNIX V6 (at least). It is true that, sadly, today you only can see
the backtrace using a debugger. In the old times there were more tools for this.

What do you think about something like:

#ifndef NDEBUG
#define fatal(...) fatal_error(__FILE__, __LINE__, __VA_ARGS__)
#define fatal(...) abort()

fatal_error(char *fname, int lineno, char *fmt, ...)
        va_list va;

        va = va_start(va, fmt);
        vfprintf(stderr, fmt, va);
        fputc('\n', stderr);

I know that '#define fatal(...)' is not 100% portable (this is a bit pedantic anyway),
but it is already used in the macro DBG(), so it does not reduce the portability
of the code.

Then, we can try to find a way to have all these strings that you added only
when NDEBUG is not defined, because I am a bit worried about the increment
of the binary due to them.

I am going to send this mail to the mailing list too. Please, could you try to
subscribe again?

To unsubscribe send a mail to scc-dev+unsubscribe_at_simple-cc.org
Received on Thu 02 Mar 2023 - 13:49:59 CET

This archive was generated by hypermail 2.3.0 : Fri 21 Apr 2023 - 16:20:42 CEST