Re: test failures building 5.93 and hpux compiler patch

[Paul Eggert]

"Peter O'Gorman" <address@hidden> writes:

> In sort.c's check function there is a variable named nonunique, which is
> declared as type bool. The code later does a compare:
> if (<bool,true> <= (int)-1) error
> xlc decided that the comparison was true. The solution is to declare
> nonunique as an int type.

I've looked into the bool problem some more, and have found the following
trouble reports with respect to the way gnulib currently handles _Bool
and <stdbool.h>:

Some HP-UX C compilers mishandle _Bool (internal compiler error),
independently of whether <stdbool.h> works.  E.g.,
<http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html>,
<http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html>.

IBM C compiler mishandles sign-extension when combining _Bool with int.  E.g.,
<http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html>.

I installed this patch into coreutils in an attempt to work around all
these problems.  I'll also suggest a similar patch to gnulib.

2005-11-25  Paul Eggert  <address@hidden>

        * lib/Makefile.am (stdbool.h): Just copy stdbool_.h; no need to sed
        any more.
        * lib/stdbool_.h: Simplify greatly, under the assumption that these
        days most people use C99-compatible compilers to debug, so it's
        not worth worrying about catering to older compilers for that.
        This works around some porting problems with HP-UX compilers.
        (false, true) [defined __BEOS__]: Don't #undef; no longer needed.
        (_Bool): typedef to bool if C++ or BeOS, and #define to signed char
        otherwise.

        * m4/stdbool.m4 (AM_STDBOOL_H): Don't bother substituting HAVE__BOOL;
        no longer needed.
        (gl_STDBOOL_H): New macro, from gnulib.
        (AC_HEADER_STDBOOL): Sync with gnulib.

Index: lib/Makefile.am
===================================================================
RCS file: /fetish/cu/lib/Makefile.am,v
retrieving revision 1.236
retrieving revision 1.239
diff -p -u -r1.236 -r1.239
--- lib/Makefile.am     24 Nov 2005 06:48:55 -0000      1.236
+++ lib/Makefile.am     26 Nov 2005 06:58:34 -0000      1.239
@@ -123,11 +123,11 @@ CLEANFILES += charset.alias ref-add.sed 
 
 BUILT_SOURCES += $(STDBOOL_H)
 EXTRA_DIST += stdbool_.h
-MOSTLYCLEANFILES += stdbool.h stdbool.ht
+MOSTLYCLEANFILES += stdbool.h stdbool.h-t
 # Create stdbool.h on systems that lack a working one.
 stdbool.h: stdbool_.h
-       sed -e 's/@''HAVE__BOOL''@/$(HAVE__BOOL)/g' $(srcdir)/stdbool_.h > 
address@hidden
-       mv address@hidden $@
+       cp $(srcdir)/stdbool_.h address@hidden
+       mv address@hidden $@
 
 BUILT_SOURCES += $(ALLOCA_H)
 EXTRA_DIST += alloca_.h
Index: lib/stdbool_.h
===================================================================
RCS file: /fetish/cu/lib/stdbool_.h,v
retrieving revision 1.5
retrieving revision 1.6
diff -p -u -r1.5 -r1.6
--- lib/stdbool_.h      14 May 2005 07:58:07 -0000      1.5
+++ lib/stdbool_.h      26 Nov 2005 06:37:31 -0000      1.6
@@ -1,4 +1,4 @@
-/* Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
+/* Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
    Written by Bruno Haible <address@hidden>, 2001.
 
    This program is free software; you can redistribute it and/or modify
@@ -54,35 +54,45 @@
 /* 7.16. Boolean type and values */
 
 /* BeOS <sys/socket.h> already #defines false 0, true 1.  We use the same
-   definitions below, but temporarily we have to #undef them.  */
+   definitions below, which is OK.  */
 #ifdef __BEOS__
 # include <OS.h> /* defines bool but not _Bool */
-# undef false
-# undef true
 #endif
 
-/* For the sake of symbolic names in gdb, we define true and false as
-   enum constants, not only as macros.
-   It is tempting to write
-      typedef enum { false = 0, true = 1 } _Bool;
-   so that gdb prints values of type 'bool' symbolically. But if we do
+/* C++ and BeOS have a reliable _Bool.  Otherwise, since this file is
+   being compiled, the system <stdbool.h> is not reliable so assume
+   that the system _Bool is not reliable either.  Under that
+   assumption, it is tempting to write
+
+      typedef enum { false, true } _Bool;
+
+   so that gdb prints values of type 'bool' symbolically.  But if we do
    this, values of type '_Bool' may promote to 'int' or 'unsigned int'
    (see ISO C 99 6.7.2.2.(4)); however, '_Bool' must promote to 'int'
-   (see ISO C 99 6.3.1.1.(2)).  So we add a negative value to the
-   enum; this ensures that '_Bool' promotes to 'int'.  */
-#if !(defined __cplusplus || defined __BEOS__)
-# if address@hidden@
-#  if defined __SUNPRO_C && (__SUNPRO_C < 0x550 || __STDC__ == 1)
-    /* Avoid stupid "warning: _Bool is a keyword in ISO C99".  */
-#   define _Bool signed char
-enum { false = 0, true = 1 };
-#  else
-typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
-#  endif
-# endif
-#else
+   (see ISO C 99 6.3.1.1.(2)).  We could instead try this:
+
+      typedef enum { _Bool_dummy = -1, false, true } _Bool;
+
+   as the negative value ensures that '_Bool' promotes to 'int'.
+   However, this runs into some other problems.  First, Sun's C
+   compiler when (__SUNPRO_C < 0x550 || __STDC__ == 1) issues a stupid
+   "warning: _Bool is a keyword in ISO C99".  Second, IBM's AIX cc
+   compiler 6.0.0.0 (and presumably other versions) mishandles
+   subscripts involving _Bool (effectively, _Bool promotes to unsigned
+   int in this case), and we need to redefine _Bool in that case.
+   Third, HP-UX 10.20's C compiler lacks <stdbool.h> but has _Bool and
+   mishandles comparisons of _Bool to int (it promotes _Bool to
+   unsigned int).
+
+   The simplest way to work around these problems is to ignore any
+   existing definition of _Bool and use our own.  */
+
+#if defined __cplusplus || defined __BEOS__
 typedef bool _Bool;
+#else
+# define _Bool signed char
 #endif
+
 #define bool _Bool
 
 /* The other macros must be usable in preprocessor directives.  */
Index: m4/stdbool.m4
===================================================================
RCS file: /fetish/cu/m4/stdbool.m4,v
retrieving revision 1.6
diff -p -u -r1.6 stdbool.m4
--- m4/stdbool.m4       7 Oct 2005 18:53:20 -0000       1.6
+++ m4/stdbool.m4       26 Nov 2005 07:00:33 -0000
@@ -11,7 +11,7 @@ AC_DEFUN([AM_STDBOOL_H],
 [
   AC_REQUIRE([AC_HEADER_STDBOOL])
 
-  # Define two additional variables used in the Makefile substitution.
+  # Define an additional variable used in the Makefile substitution.
 
   if test "$ac_cv_header_stdbool_h" = yes; then
     STDBOOL_H=''
@@ -19,15 +19,11 @@ AC_DEFUN([AM_STDBOOL_H],
     STDBOOL_H='stdbool.h'
   fi
   AC_SUBST([STDBOOL_H])
-
-  if test "$ac_cv_type__Bool" = yes; then
-    HAVE__BOOL=1
-  else
-    HAVE__BOOL=0
-  fi
-  AC_SUBST([HAVE__BOOL])
 ])
 
+# AM_STDBOOL_H will be renamed to gl_STDBOOL_H in the future.
+AC_DEFUN([gl_STDBOOL_H], [AM_STDBOOL_H])
+
 # This macro is only needed in autoconf <= 2.59.  Newer versions of autoconf
 # have this macro built-in.
 
@@ -79,7 +75,7 @@ AC_DEFUN([AC_HEADER_STDBOOL],
              reject this program, as the initializer for xlcbug is
              not one of the forms that C requires support for.
              However, doing the test right would require a run-time
-             test, and that would make crosss-compilation harder.
+             test, and that would make cross-compilation harder.
              Let us hope that IBM fixes the xlc bug, and also adds
              support for this kind of constant expression.  In the
              meantime, this test will reject xlc, which is OK, since
@@ -87,10 +83,15 @@ AC_DEFUN([AC_HEADER_STDBOOL],
           char digs[] = "0123456789";
           int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
          #endif
+         _Bool q = true;
+         _Bool *pq = &q;
        ],
        [
-         return (!a + !b + !c + !d + !e + !f + !g + !h + !i + !j + !k + !l
-                 + !m + !n + !o + !p);
+         *pq |= q;
+         *pq |= ! q;
+         /* Refer to every declared value, to avoid compiler optimizations.  */
+         return (!a + !b + !c + !d + !e + !f + !g + !h + !i + !!j + !k + !!l
+                 + !m + !n + !o + !p + !q + !pq);
        ],
        [ac_cv_header_stdbool_h=yes],
        [ac_cv_header_stdbool_h=no])])