bug-gnulib
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]