[Top][All Lists]

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

Re: bool and C23

From: Zack Weinberg
Subject: Re: bool and C23
Date: Mon, 22 Aug 2022 16:58:36 -0400
User-agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a

Please note consolidated reply to both Paul and Bruno.

On Sun, Aug 21, 2022, at 5:25 PM, Paul Eggert wrote:
> On 8/21/22 07:59, Zack Weinberg wrote:
>> Paul Eggert:
>>> Zack Weinberg:
>>>> @defmac AC_C_BOOL (@ovar{if-required})
>>> How about if we omit the IF-REQUIRED parameter?
>> Taking out the "optional" mode will mean that regenerating the the
>> configure script of a package that uses the stdbool module, with
>> Autoconf 2.72, will quietly bump its minimum C compiler requirement
>> to C99.  Are we okay with that?
> Yes, I think so. I believe Gawk was the last Gnulib-using project that
> wanted portability to C89, and Gawk dropped that requirement a few years
> ago.

OK, I’ll proceed on the assumption this is fine unless we hear
otherwise, and I’ll make sure both Autoconf NEWS and the manual make
the implications clear.

> More precisely, the idea is that in
> <>
> we'd change "<stdbool.h>, assuming the stdbool module is used. See
> stdbool.h." to something like "bool, true, and false (perhaps via
> <stdbool.h>); see the bool module." The stdbool module would become
> obsolescent.

There isn’t a bool module right now, are you proposing to add one?
To be clear, I want to get to where _no_ Gnulib module is required for
bool; AC_C_BOOL by itself should be enough.

>> I think we still need C_BOOL_DEFINITION even if we make that change,
>> because apparently there exist(ed?) compilers that provide _Bool but
>> not stdbool.h.
> Apparently OS X had that problem as recently as 2018
> <> so I guess such a
> workaround would be helpful for some apps. I'm not sure Gnulib will need
> it though.

Again, AC_C_BOOL by itself is supposed to be all you need (in the
common case where autoheader is in use).

> Sure, but why can't the non-autoheader case define bool, false, and true
> instead of defining C_BOOL_DEFINITION? That will keep the code simpler
> for these people.

I don’t understand what you are suggesting here.

> one possibility
> is that 'true' is defined by the system's <stdbool.h> which says
> "#define true (!0)". The C standard allows this.

I don’t think it does? N1570 (C11-in-all-but-name) 7.18p3 says “`true`
expands to the integer constant 1” and “`false` expands to the integer
constant 0.”  No leeway at all there.  I don’t have my copy of C99 on
this computer, but I doubt it says anything different.

>> I meant to ask you why the Gnulib stdbool module uses "signed char"
>> as the fallback underlying type for bool.
> I don't recall exactly but I can imagine a couple of good reasons.
> First, it makes it more likely you'll get a type clash if you mistakenly
> confuse int for bool in function signature compiled by an older
> compiler. Second, it makes it less likely that there would be a clash if
> some code is compiled with a compiler that has a working bool of size 1
> (the most common implementation I think), whereas other code is compiled
> with Gnulib's substitute for bool.

Hm, OK, I guess.  I’m still worried about undesirable integer
promotions but I guess those happen with _Bool used in arithmetic
expressions too (since it has the lowest possible integer conversion

On Sun, Aug 21, 2022, at 5:34 PM, Bruno Haible wrote:
>   * In C++ mode,
>     [cstdbool may include] various OS stuff, and should therefore be
>     avoided when possible. Since a compilation unit cannot be ISO C 23
>     and C++ at the same time, it is easy to achieve: Wrap the new
>     config.h additions in
>       #ifndef __cplusplus
>       ...
>       #endif

Yes, this was already my plan.  Do you think it’s worth mentioning
this issue in Autoconf’s documentation (it already says “stdbool.h
should not be included from C++” but not why).

>   * In C mode: […] it is OK to #include <stdbool.h>, since it
>     does not include header files with function declarations, only
>     header files with macro definitions.

We _could_ still get errors from -Wredundant-decls -Werror or
equivalent, but I think that’s probably okay to live with.

>   - Determine GL_GENERATE_STDBOOL_H as in gnulib/m4/stdbool.m4,

It looks like the only thing gl_STDBOOL_H does, that my current draft
of AC_C_BOOL doesn’t do, is refuse to use an existing <stdbool.h> from
C++ on Solaris.  Given that my current draft _never_ uses <stdbool.h>
from C++, I think we can just scrap that part.

Looking at the existing Gnulib code, though, suggests another possible
reason why we might need the fallback code to `signed char` (or
Gnulib’s enumeration): allegedly C99-compliant compilers whose Boolean
implementation is buggy.  My AC_C_BOOL preserves the existing test for
a buggy Boolean type, from AC_CHECK_HEADER_STDBOOL, so, if we do as
Paul suggests and make configure error out when there’s no usable
Boolean, that will hard reject those compilers as well.  I’m fine with
that.  Are you fine with that?


reply via email to

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