Re: fpurge.c error when building m4 1.4.11

[Bruno Haible]

Hello Alain,

Thanks for the report. It means the extended stdio functions tests passed
and are therefore ok. Fine!

> Another problem came in:
> 
> | gcc  -I.     -g -O2 -c memchr2.c
> | memchr2.c:86: two `l's in integer constant
> | make[3]: *** [memchr2.o] Error 1
> | make[3]: Leaving directory `/tmp/m4-1.4.10b.27-14840/lib'
> | make[2]: *** [all] Error 2
> | make[2]: Leaving directory `/tmp/m4-1.4.10b.27-14840/lib'
> | make[1]: *** [all-recursive] Error 1
> | make[1]: Leaving directory `/tmp/m4-1.4.10b.27-14840'
> | make: *** [all] Error 2
> 
> And later during make check:
> 
> | gcc  -I. -I../lib  -I. -I. -I.. -I./.. -I../lib -I./../lib   -g -O2 -c 
> test-stdint.c
> | test-stdint.c:249: two `l's in integer constant
> | make[5]: *** [test-stdint.o] Error 1
> | make[5]: Leaving directory `/tmp/m4-1.4.10b.27-14840/tests'
> | make[4]: *** [check-am] Error 2
> | make[4]: Leaving directory `/tmp/m4-1.4.10b.27-14840/tests'
> | make[3]: *** [check-recursive] Error 1
> | make[3]: Leaving directory `/tmp/m4-1.4.10b.27-14840/tests'
> | make[2]: *** [check] Error 2
> | make[2]: Leaving directory `/tmp/m4-1.4.10b.27-14840/tests'
> | make[1]: *** [check-recursive] Error 1
> | make[1]: Leaving directory `/tmp/m4-1.4.10b.27-14840'
> | make: *** [check] Error 2
> 
> This is due to the gcc 2.7.2.1 preprocessor unable to calculate or
> compare long longs.

Yes, your analysis is correct. Last year, Paul Eggert decided that
we had long enough supported compilers with pre-C99 preprocessors.
Yes, we want to use UINTMAX_MAX in preprocessor expressions.

Nevertheless, in memchr2.c it would be possible to write an if (...)
instead of #if. This will cause warnings on compilers which don't have
64-bit integers at all; but it will allow compilation on compilers which
have 64-bit integers in the expressions but not in the preprocessor.
Eric, do you agree?

> But some packages (gettext 0.17) ./configure check is stricter, and then
> long longs are not found.

gettext will return to the less strict test, since it borrows this test from
gnulib.

> Then during make check, 6 of 53 tests failed:
> 
> | test-frexpl.c:100: assertion failed
> | FAIL: test-frexpl
> 
> mantissa=NaN, x=NaN, but ASSERT (mantissa == x) fails...
>
> | test-isnanl.h:55: assertion failed
> | FAIL: test-isnanl-nolibm
> 
> | test-vasnprintf-posix.c:557: assertion failed
> | FAIL: test-vasnprintf-posix
> 
> result="nan 33", so ASSERT (strcmp (result, "-inf 33") == 0) fails. This
> nan/-inf failure happens 9 times, as well as 9 times in the following
> test:
> 
> | test-vasprintf-posix.c:538: assertion failed
> | FAIL: test-vasprintf-posix

Your compiler evaluates -1.0L / 0.0L to NaN. Not dramatic, m4 should be
usable nevertheless.

> | test-fseeko.c:62: assertion failed
> | ./test-fseeko.sh: line 3: 25399 IOT trap/Abort          (core dumped) 
> ./test-fseeko${EXEEXT} 1 <"$srcdir/test-fseeko.sh"
> | FAIL: test-fseeko.sh
> 
> | test-ftello.c:107: assertion failed
> | ./test-ftello.sh: line 3: 25403 IOT trap/Abort          (core dumped) 
> ./test-ftello${EXEEXT} 1 <"$srcdir/test-ftello.sh"
> | FAIL: test-ftello.sh
> 
> ch=123 ftell=-1 ftello=123. Line 108 also fails.

stdio bugs in your libc. This platform is already obsolete since glibc-2.0
was released; that was more than 10 years ago, or more than 3 average computer
generations. I'm therefore not willing to put effort into working around
these bugs that have been fixed in glibc a long, long time ago.

Bruno