[RFC v2 1/3] cdefs: Add __bool

Joseph Myers josmyers@redhat.com
Tue Sep 2 16:42:08 GMT 2025


On Wed, 3 Sep 2025, Xi Ruoyao wrote:

> > Plus, we already require 'long long' to exist (<stdlib.h> at least uses
> > freely).  When was it added to GCC?  That would help determining an
> > implicit version we're already requiring.
> 
> commit 795add948b87c51500c306fd95acf3388787e786
> Author: Vladimir N. Makarov <vmakarov@cygnus.com>
> Date:   Wed Jul 8 12:16:05 1998 +0000
> 
>     toplev.c (lang_options): Add -Wlong-long, -Wno-long-long options.
> 
> The first release containing this commit is egcs-1.1.0.

1. The version adding some particular warning option relating to long long 
is completely irrelevant here.

2. You can see at https://gcc.gnu.org/projects/c-status.html that long 
long support was added in GCC 1.27 or before.

3. No version before GCC 2.7 is relevant for any current ABI supported by 
glibc.

4. As I noted in the previous discussion, we should actually document 
things in terms of *features* (on top of C90/C++98) required for using the 
installed headers, not compiler versions.

5. Traditionally, library functions don't use bool; they use int which is 
interpreted as a boolean.  This isn't an objection to adding new functions 
that use bool, but explains why we didn't have the issue before.

6. If these functions are genuinely header-only static inlines (which is 
also far from how we'd normally add any function to glibc), the ABI issue 
with defining them to return int for old compilers doesn't actually apply, 
because there is no ABI issue for a static inline function; there's only 
an ABI concern for declaring functions defined with external linkage in 
the library that use type bool in their interface.

7. Any new library functions, whether or not header only, need documenting 
in the GCC manual (and would also get a NEWS entry as a new feature), as 
well as testcases.

-- 
Joseph S. Myers
josmyers@redhat.com


More information about the Libc-alpha mailing list