Re: bool and C23

Paul Eggert wrote: > > #include "unitypes.h" > > > > +/* Get bool. */ > > +#include > > In examples like these would it make sense to do the following instead? > >#if !@HAVE_C_BOOL@ && !defined __cplusplus > #include >#endif No, this would not work: * @HAVE_C_BOOL@ tests

Re: bool and C23

Paul Eggert wrote: > I did notice one glitch (an unnecessary "#undef true" that is always > commented out) and a couple of minor opportunities for simplification, > and installed the attached update. OK. > Use the slightly > more-elegant ‘!true’ instead of ‘true == 1’; this shouldn’t matter >

Re: bool and C23

On 9/18/22 10:10, Bruno Haible wrote: #define true (!false) works! It evaluates to 1 and is of the right type. Thanks, that's nicer than the tricky "#define true ((bool) +1)" that I was going to suggest. I did notice one glitch (an unnecessary "#undef true" that is always commented out)

Re: bool and C23

On 9/18/22 06:33, Bruno Haible wrote: #include "unitypes.h" +/* Get bool. */ +#include In examples like these would it make sense to do the following instead? This would avoid a bit of namespace pollution. #if !@HAVE_C_BOOL@ && !defined __cplusplus #include #endif

Re: bool and C23

Paul Eggert wrote on 2022-09-10: > I installed into Gnulib the stdbool patches ... > > After we have more experience with this in Gnulib, we can start thinking > about updating Autoconf. As part of this "gathering experience", I compiled a gnulib testdir with various compilers on various

Re: bool and C23

Paul Eggert wrote: > I installed into Gnulib the stdbool patches ... The changes to the files lib/unicase.in.h lib/unictype.in.h lib/unigbrk.in.h lib/unistr.in.h are not good, because these files ultimately get installed as public header files: 1. They get copied to libunistring, with

Re: bool and C23

> I'm starting portability tests of it now... Result of portability testing: All is fine (no compilation error) on - glibc (Ubuntu 22.04, Debian 11.1, CentOS 7) - musl libc - GNU/Hurd - macOS - FreeBSD 11, 13.1 - NetBSD 9.0 - OpenBSD 7.0 - AIX xlc and xlclang - Solaris 10 -

Re: bool and C23

I did: > 2022-09-10 Bruno Haible > > Reorganize C++ tests for stdbool and stdbool-c99. > * tests/test-stdbool-c++.cc: Don't include if TEST_STDBOOL_H > is not defined. Add a couple of simple tests, from test-stdbool.c. Oops. This produces a compilation error with MSVC14:

Re: bool and C23

Paul Eggert wrote: > Thanks for catching that doc bug. I installed into Gnulib the stdbool > patches with a fix for that The C++ tests are strangely organized now. I'm committing this patch, so that both 'stdbool' and 'stdbool-c99' have their respective C++ tests. 2022-09-10 Bruno Haible

Re: bool and C23

Thanks for catching that doc bug. I installed into Gnulib the stdbool patches with a fix for that, and also with one small change to tests/test-stdbool.c so that it depends on HAVE_C_BOOL instead of __STDC_VERSION__. After we have more experience with this in Gnulib, we can start thinking

Re: bool and C23

On Samstag, 10. September 2022 06:43:06 CEST Paul Eggert wrote: > On 9/9/22 04:14, Bruno Haible wrote: > >I would suggest to keep*one* module, and keep it named 'stdbool'. > >Its meaning will be "provide bool, true, false according to the > > standards". > >It can invoke

Re: bool and C23

Paul Eggert wrote: > OK, attached is a revised Gnulib proposed patchset that does that. Looks all good to me. Great work, Paul! I'm starting portability tests of it now... Bruno

Re: bool and C23

Paul Eggert wrote: > To help move ahead on this, I propose the attached patches to Gnulib. > They use a simpler version of the Autoconf macro, named gl_C_BOOL to > avoid collision with any future improvements to Autoconf. My hope is > that gl_C_BOOL can be renamed to AC_C_BOOL, or something

Re: bool and C23

Zack Weinberg 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 >

Re: bool and C23

On 8/22/22 15:58, Zack Weinberg wrote: There isn’t a bool module right now, are you proposing to add one? Yes. I want to get to where _no_ Gnulib module is required for bool; AC_C_BOOL by itself should be enough. Yes, that's the long term goal. But in the shorter term Gnulib-using code

Re: bool and C23

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

Re: bool and C23

On Sun, 21 Aug 2022, Bruno Haible wrote: > > This is the situation on the various platforms: [snip] > * In C mode: does > > AIX: #include , defines only macros > FreeBSD: self-contained > Haiku: self-contained > HP-UX: #include , defines only macros > macOS:

Re: bool and C23

On Monday I wrote: > > to exclude other problems, we need to check it on a platform-by-platform > > basis. This is the situation on the various platforms: * In C++ mode, - either the C is used, - or a C++ exists that #include - or a C++ exists that #include <__config>,

Re: bool and C23

On 8/15/22 14:39, Bruno Haible wrote: to exclude other problems, we need to check it on a platform-by-platform basis. In the long run this problem will vanish, as in the long run config.h will do nothing (that's all that's needed for C23 and C++). In the shorter run I think we'll be OK for

Re: bool and C23

Paul Eggert wrote: > I installed the attached patch into Gnulib, reflecting a patch I > recently installed into Autoconf > . > > I think we need a new Autoconf macro that obsoletes