One of the tests performed by AC_HEADER_STDBOOL requires the compiler to
support certain nonstandard kinds of constant initializers. This is done
to test for a certain bug in an AIX compiler [1] at compile time, though
since the AIX compiler does not support this extension, it actually fails
before the bug can be tested for. This was considered acceptable because
the only interesting compilers of the time with a working <stdbool.h> also
had this extension.
But now we have clang. clang does not (and apparently will not [2])
support this extension, so although it has a working <stdbool.h>, the test
incorrectly fails with CC=clang:
$ (echo AC_INIT; echo AC_HEADER_STDBOOL) > configure.ac && autoconf
$ CC=clang ./configure
…
checking for stdbool.h that conforms to C99... no
checking for _Bool... yes
$ grep -A6 'checking for stdbool' config.log
configure:3090: checking for stdbool.h that conforms to C99
configure:3175: clang -c -g -O2 conftest.c >&5
conftest.c:74:16: error: initializer element is not a compile-time constant
int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 diagnostic generated.
configure:3175: $? = 1
This patch attempts to minimally change the test so that clang can compile
it. The new test is very similar to one that was known to fail with the
AIX compiler [3]; can anyone test that?
--- a/lib/autoconf/headers.m4
+++ b/lib/autoconf/headers.m4
@@ -655,8 +655,7 @@ AC_DEFUN([AC_HEADER_STDBOOL],
this with GCC, where it should work, to detect more
quickly whether someone messes up the test in the
future. */
- char digs[] = "0123456789";
- int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
+ int xlcbug = 1 / (&((char *)0 + 5)[-2 + (bool) 1] == &((char *)0)[4] ?
1 : -1);
# endif
/* Catch a bug in an HP-UX C compiler. See
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
By the way, I note also that the test also fails with CC=gcc CFLAGS='-Wall
-Werror', although for a different reason (error: the address of 's' will
always evaluate as 'true').
Anders
[1] http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
[2] http://llvm.org/bugs/show_bug.cgi?id=6976
[3] http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00106.html
