[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bool and C23

From: Bruno Haible
Subject: Re: bool and C23
Date: Mon, 15 Aug 2022 23:39:30 +0200

Paul Eggert wrote:
> I installed the attached patch into Gnulib, reflecting a patch I 
> recently installed into Autoconf 
> <https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=6dcecb780a69bd208088d666b299e92aa7ae7e80>.
> I think we need a new Autoconf macro that obsoletes AC_HEADER_STDBOOL 
> and AC_CHECK_HEADER_STDBOOL. This new macro should arrange for 'bool', 
> 'true' and 'false' to work, without programs having to include 
> stdbool.h. For C23 and C++ the new macro should do nothing. For C99 
> through C17 it should include <stdbool.h> in config.h. For pre-C99 it 
> should #define bool, true, and false in config.h.

The requirement "For C99 through C17 it should include <stdbool.h> in config.h"
is a problem. In our experience, including OS headers from config.h leads
to issues, namely:
  - other definitions in config.h may not work if OS headers have already been
  - some packages have multiple config.h, and the second one may not work
    once the first one has included OS headers,
  - the programmer may have assumed that '#include <config.h>' did not include
    anything from the OS.

The first of these problems may be resolved by ensuring that the
'#include <stdbool.h>' goes to the end of config.h, not to a random place in
the middle.

But to exclude other problems, we need to check it on a platform-by-platform

As a first step towards this goal, let's "handle" BeOS by dropping the BeOS

2022-08-15  Bruno Haible  <bruno@clisp.org>

        stdbool: Drop old BeOS support that gets in the way of ISO C 23 support.
        * lib/stdbool.in.h: Don't include <OS.h>.

diff --git a/lib/stdbool.in.h b/lib/stdbool.in.h
index 03840f10fc..2fa46724b2 100644
--- a/lib/stdbool.in.h
+++ b/lib/stdbool.in.h
@@ -58,27 +58,11 @@
 /* 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.  */
-#if defined __BEOS__ && !defined __HAIKU__
-# include <OS.h> /* defines bool but not _Bool */
-# undef false
-# undef true
 #ifdef __cplusplus
 # define _Bool bool
 # define bool bool
-# if defined __BEOS__ && !defined __HAIKU__
-  /* A compiler known to have 'bool'.  */
-  /* If the compiler already has both 'bool' and '_Bool', we can assume they
-     are the same types.  */
-#  if !@HAVE__BOOL@
-typedef bool _Bool;
-#  endif
-# else
-#  if !defined __GNUC__
+# if !defined __GNUC__
    /* If @HAVE__BOOL@:
         Some HP-UX cc and AIX IBM C compiler versions have compiler bugs when
         the built-in _Bool type is used.  See
@@ -98,10 +82,10 @@ typedef bool _Bool;
           "Invalid enumerator. (badenum)" with HP-UX cc on Tru64.
         The only benefit of the enum, debuggability, is not important
         with these compilers.  So use 'signed char' and no enum.  */
-#   define _Bool signed char
-#  else
+#  define _Bool signed char
+# else
    /* With this compiler, trust the _Bool type if the compiler has it.  */
-#   if !@HAVE__BOOL@
+#  if !@HAVE__BOOL@
    /* For the sake of symbolic names in gdb, define true and false as
       enum constants, not only as macros.
       It is tempting to write
@@ -112,7 +96,6 @@ typedef bool _Bool;
       (see ISO C 99  So add a negative value to the
       enum; this ensures that '_Bool' promotes to 'int'.  */
 typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
-#   endif
 #  endif
 # endif
 # define bool _Bool

reply via email to

[Prev in Thread] Current Thread [Next in Thread]