[Bug-gnulib] proposed simplification of lib/stdbool_.h

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> FYI, a recent change to tr exposed what looks like a serious bug in
> HP's /bin/cc compiler.

I suppose we could fix this portability problem by using Autoconf to
look for the bug and complicating lib/stdbool_.h accordingly.  But I
propose a simpler fix, namely to reorient stdbool_.h so that it is a
minimal substitute for stdbool.h on older systems, rather than
attempting to be a "nice-for-debugging" or "efficient" substitute.

Part of it is that I'd rather not worry about porting the quirks of
this .h file to other compilers with weird bugs.

Part of this is because I don't understand the current stdbool_.h.
If __BEOS__ is defined, for example, stdbool_.h does the equivalent of:

   /* BeOS <sys/socket.h> already #defines false 0, true 1.  We use the same
      definitions below, but temporarily we have to #undef them.  */
   #include <OS.h> /* defines bool but not _Bool */
   #undef false
   #undef true

   typedef bool _Bool;
   #define bool _Bool
   #define false 0
   #define true 1

But if <sys/socket.h> #defines false 0, true 1, there's no point to
doing the first half of the above-quoted extract.  So either the
comment here is wrong or the code (or my understanding of it :-).

While we're on the subject of stdbool_.h, I don't see the current
utility of defining 'false' and 'true' as enum constants on older,
nonstandard platforms when they're not defined on newer, standard
ones.  Even if this hack was useful in the old days, it's not that
useful now and it makes stdbool_.h harder to follow so let's just omit
it.

(Whew!  Thanks for listening to my rants. :-)

Anyway, here's a proposed patch for all the above.

2004-06-01  Paul Eggert  <address@hidden>

        * stdbool_.h [__BEOS__]: Don't include <OS.h> or #undef false
        and true.
        (_Bool): #define to signed char if
        @HAVE__BOOL@ || !(defined __cplusplus || defined __BEOS__,
        instead of the more-complicated rule.  This avoids a bug with
        HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003].
        (false, true): Do not define as enum values.  Ordinary <stdbool.h>
        doesn't, and there's less and less utility of doing this only on
        older, nonstandard platforms.

Index: lib/stdbool_.h
===================================================================
RCS file: /cvsroot/gnulib/gnulib/lib/stdbool_.h,v
retrieving revision 1.5
diff -p -c -r1.5 stdbool_.h
*** lib/stdbool_.h      27 Oct 2003 13:58:34 -0000      1.5
--- lib/stdbool_.h      1 Jun 2004 07:52:49 -0000
***************
*** 53,85 ****
  
  /* 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.  */
! #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
!    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
  typedef bool _Bool;
  #endif
--- 53,69 ----
  
  /* 7.16. Boolean type and values */
  
! /* It is tempting to use the system _Bool if available, but it is
!    buggy on at least one system: HP aC++/ANSI C B3910B A.05.55 [Dec 04
!    2003] miscalculates sizes involving _Bool.  Conversely we must take
!    care when typedefing _Bool even when the system lacks it, as SunPRO
!    C before 5.5 lacks _Bool but prints a stupid "warning: _Bool is a
!    keyword in ISO C99" if you typedef _Bool.  If we're not sure that
!    plain bool suffices, the simplest way out is to define _Bool as a
!    macro; this overrides any system _Bool.  */
  
! #if @HAVE__BOOL@ || !(defined __cplusplus || defined __BEOS__)
! # define _Bool signed char
  #else
  typedef bool _Bool;
  #endif