Hi,
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__)
#else
#define fatal(...) abort()
#endif
void
fatal_error(char *fname, int lineno, char *fmt, ...)
{
va_list va;
va = va_start(va, fmt);
vfprintf(stderr, fmt, va);
fputc('\n', stderr);
abort();
}
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?
Regards,
--
To unsubscribe send a mail to scc-dev+unsubscribe_at_simple-cc.org
Received on Thu 02 Mar 2023 - 13:49:59 CET