Re: bool and C23

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


[cc'ing this to bug-gnulib since it's Gnulib-relevant. This follows up on the thread starting here:

On 8/21/22 07:59, Zack Weinberg wrote:

  > @defmac AC_C_BOOL (@ovar{if-required})

How about if we omit the IF-REQUIRED parameter? It matters only to
people who still want to port to pre-C99 compilers.
That does simplify things quite a bit.  I didn't do it that way to
begin with because the Gnulib stdbool module is still catering to
pre-C99 compilers, and I want this to be a drop-in upgrade from that
as well as from direct use of AC_[CHECK_]HEADER_STDBOOL.  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.

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.

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. Bruno would know better than I.

   Keeping C_BOOL_DEFINITION also means that it's simpler
to put the "optional" mode back if it turns out, after 2.72 comes out,
that we need it.  The code for people not using autoheader becomes

#include "config.h"
#ifndef __cplusplus
#  include <stdbool.h>
# elif defined C_BOOL_DEFINITION
#  define bool  C_BOOL_DEFINITION
#  define false 0
#  define true  1
# endif

which really isn't that bad IMHO.

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.

  > Ensure that @code{false} and @code{true} are usable as integer
constants that are equal to 0 and 1, respectively.

Change "integer constants" to "integer constant expressions, suitable
for use in #if preprocessing directives,".
I will add something about 'true' and 'false' working in #if but I
don't want to use the phrase "integer constant expression" because
that makes it sound like the macro expansion is more complicated than
just an integer literal.

In theory it might be more complicated. This is because one possibility is that 'true' is defined by the system's <stdbool.h> which says "#define true (!0)". The C standard allows this. I didn't want the Autoconf manual to promise more than what the C standard promises.

  > @command{configure} will arrange to make @code{bool} a synonym for
  > @code{int},

Change "@code{int}" to "a type that promotes to @code{int}".
This text will be dropped anyway if we drop the "optional" mode, but
your comment reminds me that 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.

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux