Alejandro Colomar wrote: > I see: > > You cannot assume that _Bool is a typedef; it might be a macro. > For example, C23 allows _Bool to be a macro. > > _Bool was never a typedef. It's a keyword.
In ISO C 99, it's a keyword, yes. I'm updating that doc. But in older Mac OS X and FreeBSD, it can be a typedef. For example, in FreeBSD 12 <sys/types.h> and <stdbool.h>: #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 && !defined(__INTEL_COMPILER) typedef int _Bool; #endif > I also see: > > Casts and automatic conversions to ‘bool’ don’t test against the > zero value or the null pointer, as they should. Such casts > should only be used if the value is known to be equal to 0 or 1. > > Where does this happen? On the same platforms where _Bool is a typedef. Bruno 2025-11-11 Bruno Haible <[email protected]> doc: Tweak wording about _Bool. Reported by Alejandro Colomar <[email protected]> in <https://lists.gnu.org/archive/html/bug-gnulib/2025-11/msg00106.html>. * doc/posix-headers/stdbool.texi: State that _Bool may be a keyword. diff --git a/doc/posix-headers/stdbool.texi b/doc/posix-headers/stdbool.texi index dc4acc4f3f..0c841cfe5d 100644 --- a/doc/posix-headers/stdbool.texi +++ b/doc/posix-headers/stdbool.texi @@ -34,8 +34,12 @@ the program is intended to be compiled by a C++ compiler. (With the advent of C23, @samp{_Bool} is obsolescent anyway.) @item -You cannot assume that @code{_Bool} is a typedef; it might be a macro. +You cannot assume that @code{_Bool} is a keyword or a typedef; +@c In ISO C 99 § 6.4.1.(1) it is listed as a keyword. +@c Older released of Mac OS X and FreeBSD define it as a typedef. +it might be a macro. For example, C23 allows @code{_Bool} to be a macro. +@c See ISO C 23 § 6.4.1.(3) footnote 63. @item Bit-fields of type @samp{bool} are not supported. Portable code should use @samp{unsigned int foo : 1;} rather than @samp{bool foo : 1;}.
