merging stdbool changes from gnulib

[Paul Eggert]

I installed this to help merge stdbool with gnulib:

2006-01-25  Paul Eggert  <address@hidden>

        Merge from gnulib; we still don't quite match exactly,
        but we're getting closer.
        * lib/stdbool_.h (true, false) [defined __BEOS__]: undef, as before.
        (_Bool) address@hidden@ && defined __GNUC__]: Use an enum
        rather than a #define.
        * m4/stdbool.m4 (AC_HEADER_STDBOOL): Add some comments.

Index: lib/stdbool_.h
===================================================================
RCS file: /fetish/cu/lib/stdbool_.h,v
retrieving revision 1.7
diff -p -u -r1.7 stdbool_.h
--- lib/stdbool_.h      13 Dec 2005 19:42:27 -0000      1.7
+++ lib/stdbool_.h      25 Jan 2006 18:28:44 -0000
@@ -1,4 +1,4 @@
-/* Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
+/* Copyright (C) 2001, 2002, 2003, 2006 Free Software Foundation, Inc.
    Written by Bruno Haible <address@hidden>, 2001.
 
    This program is free software; you can redistribute it and/or modify
@@ -54,47 +54,60 @@
 /* 7.16. Boolean type and values */
 
 /* BeOS <sys/socket.h> already #defines false 0, true 1.  We use the same
-   definitions below, which is OK.  */
+   definitions below, but temporarily we have to #undef them.  */
 #ifdef __BEOS__
 # include <OS.h> /* defines bool but not _Bool */
+# undef false
+# undef true
 #endif
 
-/* C++ and BeOS have a reliable bool (and _Bool, if it exists).
-   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
+/* 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
    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)).  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.  */
+   (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'.  This works
+   with older GCC versions that do not have a working <stdbool.h>,
+   and it makes bool easier to to debug, so we use this with GCC.
+
+   This approach into problems on some non-GCC platforms; the simplest
+   way to work around them is to ignore any existing definition of
+   _Bool and use our own.  */
 
 #if defined __cplusplus || defined __BEOS__
+  /* A compiler known to have 'bool'.  */
+  /* If the compiler already has both 'bool' and '_Bool', we can assume they
+     are the same types.  */
 # if address@hidden@
 typedef bool _Bool;
 # endif
 #else
-# define _Bool signed char
+# if @HAVE__BOOL@ || ! defined __GNUC__
+    /* The compiler has _Bool, or it is not GCC.  Recall that this
+       code is used only if <stdbool.h> does not work, so something is
+       odd if there is a _Bool.  */
+
+    /* Some HP-UX cc and AIX IBM C compiler versions have compiler bugs when
+       the built-in _Bool type is used.  See
+         http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
+         http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
+         http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
+       With SunPRO C, avoid stupid
+         "warning: _Bool is a keyword in ISO C99".
+       With IRIX cc, avoid stupid
+         "warning(1185): enumerated type mixed with another type".
+       In general, there are enough problems with older compilers like
+       this that it's safer to avoid their _Bool entirely when
+       <stdbool.h> doesn't work.  */
+#  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
-
 #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.9
diff -p -u -r1.9 stdbool.m4
--- m4/stdbool.m4       14 Dec 2005 01:17:28 -0000      1.9
+++ m4/stdbool.m4       25 Jan 2006 18:28:44 -0000
@@ -1,6 +1,6 @@
 # Check for stdbool.h that conforms to C99.
 
-dnl Copyright (C) 2002-2005 Free Software Foundation, Inc.
+dnl Copyright (C) 2002-2006 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
@@ -77,7 +77,7 @@ AC_DEFUN([AC_HEADER_STDBOOL],
          #if defined __xlc__ || __GNUC__
           /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
              reported by James Lemley on 2005-10-05; see
-             
<http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html>.
+             
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
              This test is not quite right, since xlc is allowed to
              reject this program, as the initializer for xlcbug is
              not one of the forms that C requires support for.
@@ -86,10 +86,17 @@ AC_DEFUN([AC_HEADER_STDBOOL],
              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
-             our stdbool.h substitute should suffice.  */
+             our stdbool.h substitute should suffice.  We also test
+             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);
          #endif
+         /* Catch a bug in an HP-UX C compiler.  See
+            http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
+            
http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
+          */
          _Bool q = true;
          _Bool *pq = &q;
        ],