Re: abort() traceability

[Bruno Haible]

Sam Steingold wrote:
> I am not saying that abort() is wrong.
> I am saying that it must be accompanied by a meaningful message.

OK, this is a different issue.

> E.g, "Gnulib.drop_privileges_permanently: failed to drop privileges".
> Or just "Error A23Z51DT97".
> Then the user can google for the message and see what has happened, instead 
> of 
> filing a bug, identical (in essence) to 100s of already filed bugs - one for 
> each package which uses this gnulib feature.

I agree with you that shortening the reporting/feedback loop in case of hitting
an abort() call would be useful: Some users don't know how to launch gdb, some
users (on mingw) don't even possess a working gdb.

This is an issue that potentially affects all of gnulib, not just the
'idpriv-drop' module.

But OTOH I think the abort()s are being run into very rarely. We have over
400 abort() calls in gnulib, and rarely get a report of an abort() in this
code. Most likely this is because in places where we are not 99.9% sure
we use return codes, not abort(). The vision of "hundreds" of bug reports
about the same abort() is highly improbable.

Regarding the 'idpriv-drop' module: I have tested the code on a number of
relevant platforms.

What do the others think? Should we possibly extend stdlib.in.h so that
abort() becomes a macro that produces a detailed error message, similar to
what assert() does?

Bruno