Re: [Bug-gnulib] hash.c change to use abort rather than assert

[Bruno Haible]

Paul Eggert writes:

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

Yes we know that
   1. gcc had problems with assert() on Solaris in version <= 2.95.x,
      when used from shared libraries,
   2. gcc-3.x when installed with the same --prefix as an earlier
      gcc 2.95.x fails to erase the earlier installed <assert.h>.

But these problems are isolated to a single platform (Solaris) and
related to old gcc versions. This isn't enough reason for avoiding
assert().

I mean, GCC used to compile some division code incorrectly on HPPA.
Still we use division.
-
Constructors of static C++ variables didn't work in shared libraries
on SunOS4 and a recent NetBSD version. Still we use them.
-
libtool doesn't support shared libraries on AIX. Still we use libtool.

> Also, I've seen bogus warnings generated for 'assert', e.g. "warning:
> passing of non-const * pointer from const *".

And I've seen broken warnings generated for 'fprintf' and 'printf' on
SunOS4. Still I use 'fprintf' and 'printf'.

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

This would be a good reason to use aver/abort - if it would really
generate better warnings. But look here:

========================= foo.c ================================
#include <assert.h>

#define aver(X) ((X) ? (void) 0 : abort ())

unsigned int foo_assert (unsigned int x)
{
  assert (x < 0);
  return -x;
}

unsigned int foo_aver (unsigned int x)
{
  aver (x < 0);
  return -x;
}
=================================================================

$ gcc -O -Wall -c foo.c

gives no warnings, neither with assert, nor with aver.

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

I agree with you that the error message from assert() is rarely useful.

My point is that assert() does all that aver() does, PLUS it is
standard, i.e. everyone knows it. 

Bruno