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

stable branches for Gnulib

Over the last two years or so, I've noticed that we quite frequently have commits in Gnulib that fix regressions. That is, while the documentation says "The goal is to have a 100% firm interface so that maintainers can feel free to update to the code in git at any time and know that their

Re: stable branches for Gnulib

[Re-adding bug-gnulib in CC.] Bruce Korb wrote: > How about a plain "stable" branch that resolves to whatever the current > (or previous-to-current) stable branch is? That way my toy builder can > reference "stable" and I won't worry over updates to what the current > stable is. :) Thanks.

math: Fix compilation error in C++ mode on AIX 7.2 with xlclang

A testdir shows compilation errors, when built with xlclang on AIX 7.2: gmake[4]: Entering directory '/home/haible/testdir-all/build-32-xlclang/gltests' depbase=`echo test-math-c++.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ xlclang++ -qthreaded -qtls -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I../../gltests

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

string: Fix compilation error in C++ mode on AIX 7.2 with xlclang

Another compilation error with xlclang on AIX 7.2 is this one: depbase=`echo test-string-c++.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ xlclang++ -qthreaded -qtls -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I../../gltests -I.. -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I..

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: stable branches for Gnulib

Bernhard Voelker wrote: > 1. New upstream / GNU package release. > Usually, GNU maintainers pull in the latest changes from gnulib before making > a new release. Well, at that time, a lot of platform tests are done, and > most problems are found instantly, I'd say. > If not, well, then the issue

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:

stdbool C++ tests: Fix for C++20

According to , #include is no longer allowed in C++20. This patch updates our unit test accordingly. 2022-09-10 Bruno Haible stdbool C++ tests: Fix for C++20. * tests/test-stdbool-c++2.cc: Don't include in C++20 or

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

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

pipe-filter-gi: Fix test failure on native Windows

In a testdir of nearly all of gnulib, I see a test failure: FAIL: test-pipe-filter-gi2.sh The logs reveal that the test-pipe-filter-gi2 test 3 fails, with status 141. 141 being 128 + SIGPIPE, the suspicion falls on the 'sigpipe' module. And indeed, the failure occurs only if the modules

Re: stable branches for Gnulib

On 9/10/22 15:51, Bruno Haible wrote: Maintaining a stable branch is a small amount of work every month. It does not even need to happen on a regular schedule. Even a schedule of 3 months is OK. I don't have a strong opinion about it. Here are just my loose thoughts about it. a) Topic

Re: stable branches for Gnulib

On 9/10/22 20:36, Bruno Haible wrote: Bernhard Voelker wrote: 1. New upstream / GNU package release. Usually, GNU maintainers pull in the latest changes from gnulib before making a new release. Well, at that time, a lot of platform tests are done, and most problems are found instantly, I'd