[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] hash.c change to use abort rather than assert
From: |
Paul Eggert |
Subject: |
Re: [Bug-gnulib] hash.c change to use abort rather than assert |
Date: |
Tue, 26 Nov 2002 18:33:55 -0800 |
> From: Bruno Haible <address@hidden>
> Date: Tue, 26 Nov 2002 15:05:41 +0100 (CET)
>
> OK but then where's the big difference versus using assert() itself?
I've had portability problems with 'assert'. For example, I've had a
problem where GCC generated code for 'assert' that required a
particular version of a library, but the library version wasn't
checked so the program failed mysteriously only when 'assert' failed.
Also, I've seen bogus warnings generated for 'assert', e.g. "warning:
passing of non-const * pointer from const *". And I've seen compiler
bugs that occur if assert's argument contains a string or backslash
that needs quoting.
In contrast, I've never had a portability problem with abort. And GCC
can sometimes generate better warnings for abort, since it knows abort
cannot return.
Maybe you'd prefer the following solution instead?
#ifndef aver
# define aver(X) ((X) ? (void) 0 : abort ())
#endif
That way, a package maintainer who wants the traditional GNU approach
can do nothing; someone who prefers assert's messages can compile with
'aver' defined to be 'assert'; and someone who wants no code at all to
be generated (which is generally unwise these days, I think) can in
addition compile with 'NDEBUG' defined.
> I interpret the paragraph
>
> "In error checks that detect "impossible" conditions, just
> abort. There is usually no point in printing any message."
>
> as meaning "Don't waste your time writing an fprintf error message,
> setting an exit code etc."
I interpret it to mean "just abort, period".
I used to disagree with this policy (and I preferred "assert"), but as
time went on I came to prefer RMS's suggestion. Maybe I'm brainwashed
now, or maybe I no longer see the utility of printing cryptic messages.
Normally I like error messages as much as the next guy. But when the
problem is that the _programmer_ was erroneous, I'm not so sure. A
programmer error is the logical equivalent of "1 = 0"; after that
anything can follow.