[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
included,
- 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
basis.
As a first step towards this goal, let's "handle" BeOS by dropping the BeOS
support.
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
-#endif
-
#ifdef __cplusplus
# define _Bool bool
# define bool bool
#else
-# 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 6.3.1.1.(2)). 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
- bool and C23, Paul Eggert, 2022/08/13
- Re: bool and C23,
Bruno Haible <=
- Re: bool and C23, Paul Eggert, 2022/08/15
- Re: bool and C23, Zack Weinberg, 2022/08/19
- Re: bool and C23, Paul Eggert, 2022/08/20
- Re: bool and C23, Zack Weinberg, 2022/08/21
- Re: bool and C23, Paul Eggert, 2022/08/21
- Re: bool and C23, Zack Weinberg, 2022/08/22
- Re: bool and C23, Paul Eggert, 2022/08/22
- Re: bool and C23, Bruno Haible, 2022/08/22
- Re: bool and C23, Bruno Haible, 2022/08/22
- Re: bool and C23, Bruno Haible, 2022/08/21