[RFC v2 1/3] cdefs: Add __bool

Alejandro Colomar alx@kernel.org
Tue Sep 2 19:26:36 GMT 2025


Hi Joseph,

On Tue, Sep 02, 2025 at 04:42:08PM +0000, Joseph Myers wrote:
> 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.

Thanks!

> 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.

Okay; can we require that a compiler supports _Bool?  Is that too much
to ask from a compiler?

> 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.

Yup; I guessed that.  The rationale to use bool is documentation; I'm
worried that people seeing an int might be tempted to think it might
have semantics like __memcmpeq(), which they don't.

> 6. If these functions are genuinely header-only static inlines (which is 
> also far from how we'd normally add any function to glibc),

I'm neutral to the kind of function this should get.  An extern inline
is my preference, but whatever glibc maintainers prefer I'll go with it.

> 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.

Hmmm, right.

> 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.

Yeah, I explicitly said I plan to write tests in v1.  Of course, I'll
also add the glibc documentation and the manual pages.

Do you have any suggestions on how to proceed with the _Bool issue?


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250902/69372eed/attachment-0001.sig>


More information about the Libc-alpha mailing list