Re: Gnulib and nullptr (and m4_provide_if)

Hi Friends, > Le 9 févr. 2023 à 01:42, Paul Eggert a écrit : > > On 2/8/23 15:15, Bruno Haible wrote: >> m4_provide_if is not documented in the Autoconf manual. Let's hope >> it won't change incompatibly... > > Yes, I hope so too. Gnulib is already using m4_provide_if in > gnulib/m4/largefile.

Re: Bison submit patches

y to quote the > > It rationale is that caret_getc_internal already handles the CR/LF > newlines from Windows, and therefore opening the file in binary mode > avoids the horrible kludges of the Microsoft stdio runtime for O_TEXT > files. I'm installing this: commit cfef21f5b0a5

Re: Gnulib-related problems building Bison from git

Hi Bruno, > Le 13 juil. 2022 à 08:41, Akim Demaille a écrit : > > What do you think about this? Can I install it? I pushed it. Bison does not build successfully without libtextstyle without that. I've installed the following patch in Bison. C

Re: Gnulib-related problems building Bison from git

Hi Bruno, > Le 6 juil. 2022 à 07:57, Akim Demaille a écrit : > > commit 813e5a1787ed156c70bd6d4bba39a8b2db4916db > Author: Akim Demaille > Date: Mon Jul 4 07:18:07 2022 +0200 > >gnulib-tool: add support for --automake-subdir-tests > ><https://list

Re: Gnulib-related problems building Bison from git

> Le 6 juil. 2022 à 07:53, Akim Demaille a écrit : > > Here's my updated proposal. I had forgotten to s/test/tests/ in the commit message, sorry. commit 813e5a1787ed156c70bd6d4bba39a8b2db4916db Author: Akim Demaille Date: Mon Jul 4 07:18:07 2022 +0200 gnulib-tool: a

Re: Gnulib-related problems building Bison from git

the start of an evaluation >command. To please these shells, you would have to add a space, >i.e. write ( ( instead of (( I was unaware of this. Actually I should not have used (...), so I shouldn't have needed to know :) > I don't believe that the unconditional refere

Re: Gnulib-related problems building Bison from git

e to add another option, --automake-subdir-test to signal cases such as Bison's. If this is validated, I'll complete it with the doc parts. Cheers! commit b781a18296d4d5df0325f6618d296b8bac6e6b17 Author: Akim Demaille Date: Mon Jul 4 07:18:07 2022 +0200 gnulib-tool: add support

Re: Gnulib-related problems building Bison from git

Hi Paul, > Le 15 janv. 2022 à 20:51, Paul Eggert a écrit : > > I can't build Bison from Savannah git. See attached transcript, which ends: > > GEN lib/inttypes.h > make: *** No rule to make target 'textstyle.h', needed by 'all'. Stop. > > The Makefile (also attached) has a rule to build

Re: bison segv under Cygwin 64 at fatal-signal.c:318

Hi Brian, > Le 18 sept. 2021 à 19:04, Brian Inglis a > écrit : > > Thanks very much for your help Bruno, in diagnosing the issue correctly, and > providing the patch: I will ensure your patch comment gets prefixed into the > respun bison gnulib patch. > > And thanks Akim for getting Bruno in

Re: bison segv under Cygwin 64 at fatal-signal.c:318

low has commit 7818455627c5e54813ac89924b8b67d0bc869146 (HEAD -> master, origin/master, origin/HEAD) Author: Bruno Haible Date: Fri Sep 17 22:22:50 2021 +0200 threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0. Reported by Brian Inglis via Akim Demaille in <https://lists.gnu.org/ar

Re: Portability issues of inline on macOS with GCC11

> Le 13 sept. 2021 à 07:30, Bruno Haible a écrit : > > Akim Demaille wrote: >> The preprocessed source is >> >>> static [[__maybe_unused__]] void *xnrealloc (void *p, size_t n, size_t s) >>> __attribute__ ((__alloc_size__ (2, 3))); >>> static

Portability issues of inline on macOS with GCC11

Hi, If I try to update gnulib in Bison, I have the following errors using GCC 11.2.0 on macOS. > In file included from /Users/akim/src/gnu/bison/src/system.h:74, > from /Users/akim/src/gnu/bison/src/Sbitset.c:21: > /Users/akim/src/gnu/bison/lib/xalloc.h:139:1: error: 'maybe_unus

snippet/_Noreturn: Fix typo

From a report by Christopher Nielsen about Bison (which uses an almost verbatim copy of this snippet). <https://trac.macports.org/ticket/59927#comment:59> <https://trac.macports.org/ticket/59927#comment:62> Cheers! commit 964ce0a92b9ba87afe7787dc0fd5d1e1abe7214c Author: Akim De

Re: Portability issues with scractch_buffer

Hi Paul, > Le 20 janv. 2021 à 21:14, Akim Demaille a écrit : > > Hi Paul, > >> Le 20 janv. 2021 à 02:50, Paul Eggert a écrit : >> >> On 1/19/21 10:22 AM, Akim Demaille wrote: >> >>> Clang 3.3 and 3.4 cannot compile the new scratch-buffer

fprintf-posix: fix typo

Installed. Cheers! commit e639e557f1b09a4f5589377705a30c4014b76924 Author: Akim Demaille Date: Fri Mar 26 06:40:06 2021 +0100 fprintf-posix: fix typo * modules/fprintf-posix (Depends-on): Fix typo. diff --git a/ChangeLog b/ChangeLog index b9fb4b797..cac41b795 100644 --- a

Re: Portability issues with scractch_buffer

Hi Paul, > Le 20 janv. 2021 à 02:50, Paul Eggert a écrit : > > On 1/19/21 10:22 AM, Akim Demaille wrote: > >> Clang 3.3 and 3.4 cannot compile the new scratch-buffer module. On Bison's >> CI (Clang 3.4: https://api.travis-ci.org/v3/job/755133481/log.txt), there i

Portability issues with scractch_buffer

Hi all, Clang 3.3 and 3.4 cannot compile the new scratch-buffer module. On Bison's CI (Clang 3.4: https://api.travis-ci.org/v3/job/755133481/log.txt), there is: > make[2]: Entering directory `/home/travis/build/bison-3.7.4.285-a7d1a/_build' > CC lib/lib_libbison_a-bitsetv.o > CC

Re: mention the 'bitset' module on planet.gnu.org?

Hi Bruno, > Le 3 janv. 2021 à 03:19, Bruno Haible a écrit : > > Hi Akim, > > You might have noticed that we are currently publishing a news item per week > about Gnulib in https://savannah.gnu.org/news/?group=gnulib ; they get > propagated to http://planet.gnu.org/ . > > Would you want to writ

[PATCH 6/7] bitset: use integrer_length in list implementation

/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2020-11-29 Akim Demaille + + bitset: use integrer_length in list implementation + * lib/bitset/list.c (lbitset_list_reverse): Use + BITSET_FOR_EACH_BIT_REVERSE. + 2020-11-29 Akim Demaille bitset: use integrer_length in vector

[PATCH 5/7] bitset: use integrer_length in vector implementation

/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2020-11-29 Akim Demaille + + bitset: use integrer_length in vector implementation + * lib/bitset/array.c (vbitset_list_reverse): Use + BITSET_FOR_EACH_BIT_REVERSE. + 2020-11-29 Akim Demaille bitset: use integrer_length in array

[PATCH 7/7] bitset: use integrer_length in table implementation

+++ b/ChangeLog @@ -1,3 +1,9 @@ +2020-11-29 Akim Demaille + + bitset: use integrer_length in table implementation + * lib/bitset/table.c (tbitset_list_reverse): Use + BITSET_FOR_EACH_BIT_REVERSE. + 2020-11-29 Akim Demaille bitset: use integrer_length in list

[PATCH 4/7] bitset: use integrer_length in array implementation

+ modules/bitset | 1 + 4 files changed, 38 insertions(+), 10 deletions(-) diff --git a/ChangeLog b/ChangeLog index 48d6191dd..ecf0fc054 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2020-11-29 Akim Demaille + + bitset: use integrer_length in array implementation

[PATCH 3/7] bitset: style: use consistent names

24 lib/bitset/table.c | 20 ++-- 3 files changed, 30 insertions(+), 22 deletions(-) diff --git a/ChangeLog b/ChangeLog index 7f83f5e1d..48d6191dd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2020-11-29 Akim Demaille + + bitset: style: use

[PATCH 2/7] bitset: style: sort header

/ChangeLog index 67576a51f..7f83f5e1d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2020-11-29 Akim Demaille + + bitset: style: sort header + * lib/bitset/base.h (bitset_ffs): Rename as... + (bitset_ffs_): this. + (bitset_ffs_, BITSET_FOR_EACH_BIT): Move to better

[PATCH 1/7] bitset: tests: check BITSET_FOR_EACH_REVERSE

..67576a51f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2020-11-29 Akim Demaille + + bitset: tests: check BITSET_FOR_EACH_REVERSE + * tests/test-bitset.c (compare, check_zero, check_one_bit, check_ones): + Check BITSET_FOR_EACH_REVERSE. + 2020-11-28 Bruno Haible

[PATCH 0/7] bitset: use integrer_length in reverse iterations

iterations with uses of integrer_length. The test suite passes with asan and ubsan. Bison's test suite passes, but this is irrelevant, since Bison does not depend on reverse iteration. I'll push it tomorrow, unless told otherwise. Cheers! Akim Demaille (7): bitset: te

Re: bitpack search in bitsets

Hi Bruno, > Le 18 nov. 2020 à 10:53, Bruno Haible a écrit : > >> Conversely: couldn't ssfmalloc sit on top of bitset? > > Well, in ssfmalloc it is important to use the available space well. When > I use a bitset of 256 bits in order to describe which of the 16-byte blocks > of a 4096-bytes page

Re: [PATCH 0/6] bitset: more conversions to ffs

Hi Bruno, So I installed these commits. > Le 20 nov. 2020 à 00:05, Bruno Haible a écrit : > > Akim Demaille wrote: >>> Gnulib has modules integer_length, integer_length_l, integer_length_ll. >> >> Oh, yes. Why these names? > > The name 'integ

Re: [PATCH 0/6] bitset: more conversions to ffs

Hi Bruno, > Le 19 nov. 2020 à 16:04, Bruno Haible a écrit : > > Hi Akim, > >> When gnulib have fls* support, we will be able do the same for >> bitset_list_reverse > > Gnulib has modules integer_length, integer_length_l, integer_length_ll. Oh, yes. Why these names? "fls" feels more "natural

[PATCH 6/6] bitset: exercise the stats too

* tests/test-bitset.c: Display the stats at the end of the test. * lib/bitset/stats.c (bitset_log_histogram_print): When diplaying the last bin, display "256-..." rather that "256-511", since the last bin does count item greater than or equal to 256. --- lib/bitset/stats.c | 8 +++- tests/tes

[PATCH 6/6] bitset: tests: exercise the stats too

| 9 + lib/bitset/stats.c | 8 +++- tests/test-bitset.c | 4 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index cd595f41d..55c4e08e8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2020-11-19 Akim Demaille + + bitset: tests

[PATCH 5/6] bitset: tests: try harder to break it

+1,11 @@ +2020-11-19 Akim Demaille + + bitset: tests: try harder to break it + * tests/test-bitset.c (compare): Be ready to use bitsets larger than + BITSET_LIST_SIZE. + (main): Likewise. + While at it, also exercise super small bitsets. + 2020-11-19 Akim Demaille

[PATCH 4/6] bitset: use ffs where possible in the vector implementation

/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-11-19 Akim Demaille + + bitset: use ffs where possible in the vector implementation + * lib/bitset/vector.c (vbitset_list): Use BITSET_FOR_EACH_BIT. + 2020-11-19 Akim Demaille bitset: use ffs where possible in the table

[PATCH 2/6] bitset: check empty and full bitsets

--- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2020-11-19 Akim Demaille + + bitset: check empty and full bitsets + * tests/test-bitset.c (check_zero, check_ones): New. + (check_attributes): Use them. + 2020-11-19 Akim Demaille bitset: be sure to always return a

[PATCH 3/6] bitset: use ffs where possible in the table implementation

/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-11-19 Akim Demaille + + bitset: use ffs where possible in the table implementation + * lib/bitset/table.c (tbitset_list): Use BITSET_FOR_EACH_BIT. + 2020-11-19 Akim Demaille bitset: check empty and full bitsets diff --git a

[PATCH 0/6] bitset: more conversions to ffs

With this, I believe I have used ffs everywhere possible. When gnulib have fls* support, we will be able do the same for bitset_list_reverse, but I'm not sure it's a frequent need. FWIW, I have run successfully the test suite of Bison on every single bitset implementation. Che

[PATCH 1/6] bitset: be sure to always return a value

/ChangeLog @@ -1,3 +1,9 @@ +2020-11-19 Akim Demaille + + bitset: be sure to always return a value + * lib/bitset/array.c (abitset_small_list): Always update *next and + return a value. + 2020-11-17 Akim Demaille bitset: strengthen tests diff --git a/lib/bitset

Re: bitpack search in bitsets

Bruno, > Le 17 nov. 2020 à 22:50, Bruno Haible a écrit : > > Hi Akim, > > In gnulib/lib/ssfmalloc-bitmap.h there is a function > > /* Returns the smallest index k >= 0 for which the bit packet of c consecutive > bits (1 <= c <= 32) is all set in the bitmap consisting of num_words words. >

Re: [PATCH 0/6] bitset: clean up, test, fix, accelerate

Hi Bruno, > Le 17 nov. 2020 à 22:42, Bruno Haible a écrit : > > Hi Akim, > >> The last commit fixes an error caught by the >> "strengthen tests" commit. I can easily commute them if we want to >> avoid "make check" failures in the history. > > Yes, please. Some people use 'git bisect'; theref

Re: [PATCH 5/5] bitset: use ffsl to accelerate iterations over set bits

Hi Bruno, > Le 18 nov. 2020 à 04:40, Bruno Haible a écrit : > > Hi Akim, > >>> Yes, assuming you did a quick check with the unit tests: >>> ./gnulib-tool --test --single-configure bitset >> >> Yes, I did run the test suite :) >> >> Installed. Thanks! > > A testdir of all of gnulib now shows

[PATCH 0/6] bitset: clean up, test, fix, accelerate

quot;strengthen tests" commit. I can easily commute them if we want to avoid "make check" failures in the history. Cheers! Akim Demaille (6): bitset: use ffs where possible in array implementation bitset: use ffs where possible in the list implementation bitset: test: run determi

[PATCH 6/6] bitset: fix iteration over table bitsets

@@ +2020-11-17 Akim Demaille + + bitset: fix iteration over table bitsets + * lib/bitset/table.c (tbitset_list): Update bitno when windex is. + 2020-11-17 Akim Demaille bitset: rename internal details for consistency diff --git a/lib/bitset/table.c b/lib/bitset/table.c

[PATCH 5/6] bitset: rename internal details for consistency

5 + lib/bitset/table.c | 320 ++--- 2 files changed, 165 insertions(+), 160 deletions(-) diff --git a/ChangeLog b/ChangeLog index ad9c9e153..f3df478d1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-11-17 Akim Demaille + + bitse

[PATCH 4/6] bitset: strengthen tests

, 93 insertions(+), 80 deletions(-) diff --git a/ChangeLog b/ChangeLog index 82b67f481..ad9c9e153 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2020-11-17 Akim Demaille + + bitset: strengthen tests + * tests/test-bitset.c (compare): Also check count. + Deal only with

[PATCH 3/6] bitset: test: run deterministic tests on several bitset sizes

/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2020-11-17 Akim Demaille + + bitset: test: run deterministic tests on several bitset sizes + * tests/test-bitset.c (check_attributes): Run it with small and large + sizes. + 2020-11-17 Akim Demaille bitset: use ffs where

[PATCH 2/6] bitset: use ffs where possible in the list implementation

/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-11-17 Akim Demaille + + bitset: use ffs where possible in the list implementation + * lib/bitset/list.c (lbitset_list): Use BITSET_FOR_EACH_BIT. + 2020-11-17 Akim Demaille bitset: use ffs where possible in array implementation

[PATCH 1/6] bitset: use ffs where possible in array implementation

--- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-11-17 Akim Demaille + + bitset: use ffs where possible in array implementation + * lib/bitset/array.c (abitset_small_list): Use BITSET_FOR_EACH_BIT. + 2020-11-16 Bruno Haible Fix link errors on platforms with

Re: [PATCH 5/5] bitset: use ffsl to accelerate iterations over set bits

> Le 15 nov. 2020 à 19:07, Bruno Haible a écrit : > > Hi Akim, > >> Thanks for catching these errors. I have fixed them. >> Good to install? > > Yes, assuming you did a quick check with the unit tests: > ./gnulib-tool --test --single-configure bitset Yes, I did run the test suite :) Inst

Re: [PATCH 5/5] bitset: use ffsl to accelerate iterations over set bits

Hi Bruno, > Le 15 nov. 2020 à 17:42, Bruno Haible a écrit : > > Akim Demaille wrote: >> @@ -20,6 +20,7 @@ Depends-on: >> attribute >> c99 >> fopen-gnu >> +fssl > > Typo: We don't have a module named 'fssl'. Thanks for catching these errors. I have fixed them. Good to install?

[PATCH 3/5] bitset: fix the copy from lbitset to other types

/homogeneous copy. --- ChangeLog | 6 ++ lib/bitset/list.c | 11 ++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 3e3e78ed3..ff21b6631 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2020-11-15 Akim Demaille + bitset

[PATCH 2/5] bitset: making debug traces more useful

-15 Akim Demaille + bitset: making debug traces more useful + * lib/bitset.c (bitset_print): Print the bitset type in verbose node. + bitset: comment changes * lib/bitset.c: Move some documenting comments to... * lib/bitset.h: here. diff --git a/lib/bitset.c b

[PATCH 1/5] bitset: comment changes

(+), 15 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4abbcd385..f25a948eb 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2020-11-15 Akim Demaille + + bitset: comment changes + * lib/bitset.c: Move some documenting comments to... + * lib/bitset.h: here

[PATCH 4/5] bitset: more tests

| 107 2 files changed, 103 insertions(+), 9 deletions(-) diff --git a/ChangeLog b/ChangeLog index ff21b6631..713206bcf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2020-11-15 Akim Demaille + bitset: more tests + * tests/test

[PATCH 5/5] bitset: use ffsl to accelerate iterations over set bits

+++ b/ChangeLog @@ -1,5 +1,11 @@ 2020-11-15 Akim Demaille + bitset: use ffsl to accelerate iterations over set bits + Suggested by Bruno Haible. + * modules/bitset: Depend upon ffsl. + * lib/bitset/base.h (bitset_ffs, BITSET_FOR_EACH_BIT): New. + * lib/bitset/array.c

[PATCH 0/5] bitset: use ffs

OR_EACH_BIT(Pos, Word) \ for (int Pos = bitset_ffs (Word); \ 0 <= Pos;\ Word ^= 1UL << Pos, Pos = bitset_ffs (Word)) Cheers! Akim Demaille (5): bitset: comment changes bitset: making debug traces

Re: Typo in quote.h

Hi Bruno, Paul and Reuben, > Le 31 oct. 2020 à 20:41, Bruno Haible a écrit :\ > > You are right that there is a problem here: On 2012-03-07 this patch [1] > from Akim did a good thing — it made the quote.h functions' effect more > customizable — and a not so good thing: it combined the implement

Re: Portability of libtextstyle

Hi Bruno! > Le 1 août 2020 à 15:10, Bruno Haible a écrit : > > In Bison's configure.ac, you now need to write > gl_LIBTEXTSTYLE_OPTIONAL([0.20.5]) > This will guarantee that you can use ostream_printf. If an older version of > libtextstyle is installed, it will not be used. > > > 2020-08-01

Re: Portability of libtextstyle

Hi Bruno, Thanks for coming back about this! > Le 29 juil. 2020 à 11:08, Bruno Haible a écrit : > > Hi Akim, > >> Here's my proposal to update the check for libtextstyle. >> >> Cheers! >> >> commit 76c00e218869dab03ec4a1f503495e0d729d0b97 >

Re: Portability of libtextstyle

0.21 now. You can tell your users that it is a > prerequisite for proper styling support of bison-3.7. Wow... Thanks a lot for the effort! I appreciate that. Here's my proposal to update the check for libtextstyle. Cheers! commit 76c00e218869dab03ec4a1f503495e0d729d0b97 Author: Akim D

Re: Portability of libtextstyle

Hi Bruno, Thanks for the quick answer! > Le 26 juil. 2020 à 17:25, Bruno Haible a écrit : > > Hi Akim, > > The new functions (for hyperlinks and ostream_printf) are contained in > prerelease tarballs that I've been circulating, but not contained in any > release so far. I had not realized. >

Portability of libtextstyle

Hi Bruno, I have been bitten by portability issues with libtextstyle: some people have versions that don't feature ostream_printf. Unfortunately gnulib's Autoconf macros don't check for this function, so old versions of libtextstyle are accepted, and linking fails (https://lists.gnu.org/r/bug

Re: portability issues with unicodeio

; program, and found the issue. > > > 2020-07-09 Bruno Haible > > unicodeio: Fix wrong result on Solaris 11. > Reported by Kiyoshi Kanazawa > via Akim Demaille in > <https://lists.gnu.org/archive/html/bug-gnulib/2020-07/msg00036.html>. &g

portability issues with unicodeio (was: [GNU Bison 3.6.90] testsuite: 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 196 220 221 228 244 245 246 249 250 251 252 25

Hi! Bison uses gnulib's unicodeio module to emit bullets (•) portably, with a fallback to '.'. It's implemented this way (src/gram.h): > /* Fallback in case we can't print "•". */ > static inline long > print_dot_fallback (unsigned int code _GL_UNUSED, > const char *msg _GL_

Re: list: fix GCC warnings

twice. > > Better use _GL_ATTRIBUTE_MAYBE_UNUSED. Implementing the function twice means > - duplicating the parameter list, > - having no proper place for attaching a comment to the function. Very much agreed. Installed as follows. Cheers! commit d8a8fb3423499851bf06aac2302112944

list: fix GCC warnings

think the MAYBE_UNUSED attribute may harm in any way, but if we want to avoid that, the simplest would probably be to move the #if outside and implement the function twice. Cheers! commit a49be9d81e795a3f80bd08a4cfcdd74e9cd8b636 Author: Akim Demaille Date: Sun May 31 08:59:25 2020 +0200

hash: add hash_xinsert

commit 6f3f39926b3de346695e6213b9378c643dc47817 Author: Akim Demaille Date: Sun May 17 11:55:12 2020 +0200 hash: add hash_xinsert * lib/hash.h, lib/xhash.c (hash_xinsert): New. diff --git a/ChangeLog b/ChangeLog index 889c756eb..65abbb559 100644 --- a/ChangeLog +++ b/ChangeLog

announce-gen: add support for dist-lzip

I installed this. Cheers! commit 4f4779e15adb7f1c61e8e13ab2bdf08974e33945 Author: Akim Demaille Date: Sun May 10 18:11:04 2020 +0200 announce-gen: add support for dist-lzip * build-aux/announce-gen (@archive_suffixes): Add tar.lz. diff --git a/ChangeLog b/ChangeLog index

Re: m4: use AC_SUBST with two arguments when applicable

Hi Bruno, > Le 10 mai 2020 à 14:17, Bruno Haible a écrit : > > Hi Akim, > >> gl_SUBSTS([ >> GNULIB_ISWBLANK=0 >> GNULIB_ISWDIGIT=0 >> GNULIB_ISWXDIGIT=0 >> GNULIB_WCTYPE=0 >> GNULIB_ISWCTYPE=0 >> GNULIB_WCTRANS=0 >> GNULIB_TOWCTRANS=0 >> ]) >> >> which does not, to my eyes, suffer from

Re: m4: use AC_SUBST with two arguments when applicable

Hi Bruno! > Le 9 mai 2020 à 22:14, Bruno Haible a écrit : > > Hi Akim, > > (A) > I'm looking for means to avoid repetitions, and boilerplate. > > It needs to be balanced against the other characteristics of maintainability. > Two important aspects are: > (B) Making the code easy to understand

Re: m4: use AC_SUBST with two arguments when applicable

Hi Bruno, > Le 9 mai 2020 à 17:25, Bruno Haible a écrit : > > Hi Akim, > >> AC_SUBST([GNULIB_ISWBLANK], [0]) >> AC_SUBST([GNULIB_ISWDIGIT], [0]) >> AC_SUBST([GNULIB_ISWXDIGIT], [0]) >> AC_SUBST([GNULIB_WCTYPE], [0]) >> AC_SUBST([GNULIB_ISWCTYPE], [0]) >> AC_SUBST([GNULIB_WCTRANS], [0]) >>

m4: use AC_SUBST with two arguments when applicable

]) AC_SUBST([GNULIB_WCTRANS], [0]) AC_SUBST([GNULIB_TOWCTRANS], [0]) I can take care of that if there is agreement. Ok to install? commit 295dc196c4f5e186a7a435fa4c7535943e815132 Author: Akim Demaille Date: Sat May 9 14:08:12 2020 +0200 m4: use AC_SUBST with two arguments when applicable

Re: The attribute module

> Le 9 mai 2020 à 13:24, Bruno Haible a écrit : > > Hi Akim, > >>> In file included from ../lib/bitsetv.c:21: >>> In file included from ../lib/bitsetv.h:24: >>> In file included from ../lib/bitset.h:31: >>> In file included from ../lib/bitset/base.h:28: >>> ../lib/xalloc.h:43:10: warning: '_GL

Re: The attribute module

Hi Bruno, > Le 9 mai 2020 à 12:37, Bruno Haible a écrit : > > Hi Akim, > > Also, I avoid to use _GL_ATTRIBUTE_FORMAT and ATTRIBUTE_FORMAT, because of a > tricky override of 'printf' by '__printf__', done in gnulib and libintl. Then, shouldn't gnulib expose the _GL_ATTRIBUTE_FORMAT_(PRINTF|SCAN

The attribute module

Hi all, Bison started to use the new attribute module, but it generates conflicts with other modules, because one definition comes from config.h, and another from the other module's file. For instance: > In file included from ../lib/bitsetv.c:21: > In file included from ../lib/bitsetv.h:24: >

Re: bison: new module

> Le 3 mai 2020 à 12:02, Bruno Haible a écrit : > >> How about this? > > Looks good. > > After you pushed it, I'll test it from within GNU gettext. Pushed.

Re: bison: new module

>> +if _AC_DO_VAR([$1 conftest.y -o conftest.c]); then > > I would try to avoid the use of undocumented Autoconf internals. Is that > possible here? Sure. The use of _AC_DO* makes it visible in config.log, but that is not a requirement. How about this? commit 3db0ae5f4fd59

Re: bison: new module

Hi Bruno, > Le 2 mai 2020 à 19:50, Akim Demaille a écrit : > >> At configure time, both solutions are nearly on par: the time to >> create a temporary file is negligible. And both will fail the same >> way for a 'bison' program that references missing shar

Re: bison: new module

Hi Bruno, > Le 2 mai 2020 à 10:45, Bruno Haible a écrit : > > Hi Akim, > >> I was suggesting that the macro _itself_ could just >> run bison on a file with the %require. > > This sounds better than the existing code that runs '--version'. > > What about users who have non-released versions in

Re: m4/bison-i18n.m4: add --with-bisonlocaledir to assign BISON_LOCALEDIR

Bruno, Thanks for this! > Le 2 mai 2020 à 17:31, Bruno Haible a écrit : > > +BISON_LOCALEDIR="${localedir}" > +AC_ARG_WITH([bison-prefix], > + [[ with-bison-prefix=DIR search for bison's runtime data in > DIR/share]], You meant --with-bison-prefix here. Or use AS_HELP_STRING.

Re: wbswidth: portability to cygwin

umentation, wchar.h's replacement should work properly on Cygwin, but I don't know if mbswidth is expected to work. The test Denis ran below was indeed using gnulib's wchar.h. Cheers! > Le 2 mai 2020 à 12:04, Denis Excoffier a écrit : > >> On 2020-05-02 07:23,

m4/bison-i18n.m4: add --with-bisonlocaledir to assign BISON_LOCALEDIR

Hi, Someone suggested that it would be nice to force a given value to BISON_LOCALEDIR in ./configure. Are you interested in that? I'm not a huge fan of adding tons of options to configure, I would rather have this macro take incoming values of $BISON_LOCALEDIR, and of course document it with AC_A

Re: bison: new module

Hi Bruno, > Le 1 mai 2020 à 20:10, Bruno Haible a écrit : > > Hi Akim, > >> I would personally just run bison on a file with %require "VERSION". >> It was introduced in 2.2 (2006-05-19), which, I think, is old enough. >> If you agree with that approach, I can provide a patch. > > Alas, this is

Re: bison: new module

Hi Bruno, > Le 1 mai 2020 à 18:21, Bruno Haible a écrit : > > The 'parse-datetime' module has a reasonable configure check for Bison, > specifying the minimum version of Bison that is required for the particular > .y file. > > This patch moves the support to a module 'bison', that can be used i

Re: can't bootstrap bison

Hi Bruno, > Le 13 avr. 2020 à 16:45, Bruno Haible a écrit : > > Indeed, 'git submodule update --init' fixes the situation, that > 'git submodule init' could not fix: Good! I installed the following commit. Cheers! commit 64e1ff019f9318c63da67d5396ac49a0df53

Re: can't bootstrap bison

Hi Bruno, > Le 7 avr. 2020 à 10:52, Bruno Haible a écrit : > > Hi Akim, > >> $ git submodule init >> $ ./bootstrap >> ... >> ./bootstrap: some git submodules are not initialized. Run 'git submodule >> init' and bootstrap again. >> $ echo $? >> 1 > > More details: > > $ git -C submodul

Re: fstrcmp: memory is not reclaimed on exit

not like the others. > This patch, however, should work. > > > 2020-02-16 Bruno Haible > > fstrcmp: Add API to clean up resources. > Reported by Akim Demaille in > <https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00080.html>. >

Re: fstrcmp: memory is not reclaimed on exit

Hi all, > Le 22 janv. 2020 à 07:50, Akim Demaille a écrit : > > I agree, I would like to be able to explicitly release the memory. But > I can't see any API to do that in fstrcmp.c. Is this one ok? I feel > stupid to initialize the memory right before releasing, but I d

Re: fstrcmp: memory is not reclaimed on exit

. I agree, I would like to be able to explicitly release the memory. But I can't see any API to do that in fstrcmp.c. Is this one ok? I feel stupid to initialize the memory right before releasing, but I didn't find a means to check whether the tls memory was initialized. Thanks! commit

fstrcmp: memory is not reclaimed on exit

Hi! There was a recent bug report about Bison not reclaiming all its memory on exit (https://lists.gnu.org/r/bug-bison/2020-01/msg6.html). This is a not a leak, the memory is still reachable, yet we try to stay clean on exit. The traces from Valgrind are: > 10. input.at:331: testing Symbol d

Re: bug in xtime.h

Hi friends, > Le 22 déc. 2019 à 21:48, Paul Eggert a écrit : > > On 12/22/19 3:31 AM, Bruno Haible wrote: > >> diff --git a/lib/xtime.h b/lib/xtime.h >> index 77f1c30..5e0ae89 100644 >> --- a/lib/xtime.h >> +++ b/lib/xtime.h >> @@ -42,12 +42,13 @@ extern "C" { >> XTIME_INLINE xtime_t >> xtime_m

maintainer-makefile: update rule for argmatch

Installed. commit fffc8765455be047f97e632db7f30e1883c566ad Author: Akim Demaille Date: Tue Oct 22 10:28:50 2019 +0200 maintainer-makefile: update rule for argmatch * top/maint.mk (sc_prohibit_argmatch_without_use): Add ARGMATCH_DEFINE_GROUP. diff --git a/ChangeLog b/ChangeLog

bitset: let freeing functions accept NULL

I installed this. Apparently I was drunk when I wrote the example in the documentation. bitsetv does not need these changes, it is already NULL-proof. commit ac7fd66617c1a3ace838b8660e70930c4182c1e0 Author: Akim Demaille Date: Mon Oct 21 16:47:00 2019 +0200 bitset: let freeing

Re: Error compiling bison 3.4.2 on Solaris

Hi Paul, > Le 17 oct. 2019 à 21:49, Paul Eggert a écrit : > > On 10/16/19 6:36 AM, Dagobert Michelsen wrote: >> I would think these are all compiler bugs and probably wouldn’t worry too >> much. > > Thanks for mentioning the problems. > > I built and and ran the Bison tests with Bison HEAD on

Re: hash: provide hash_xinitialize

of xhash, because I see hash.h as a part of hash, not xhash. And I shamelessly decided to put the maintenance burden on Jim's shoulders. commit 734cd738f062ccbc53126d593e5ae977d77d6ee6 Author: Akim Demaille Date: Mon Sep 9 08:31:33 2019 +0200 xhash: provide hash_xinitialize Suggest

hash: provide hash_xinitialize

Hi Jim, Recently in Bison I had to check all my calls to hash_initialize for memory exhaustion. Coreutils do it by hand for some of the calls, but we could just as well provide a simple wrapper? commit 73f0aa2e58b1dabbe075ab6bf5644da36d7c72d2 Author: Akim Demaille Date: Mon Sep 9 08:31:33

Re: bitset: check memory allocation

> Le 8 sept. 2019 à 03:17, Paul Eggert a écrit : > > Thanks, and your changes all look good to me; please install when you have > the time. We can worry about the other issues later (if ever...). Installed, thanks!

Re: bitset: check memory allocation

Hi Paul, Thanks a lot for the detailed answer! > Le 5 sept. 2019 à 22:54, Paul Eggert a écrit : > > On 9/5/19 12:59 PM, Akim Demaille wrote: > >>EBITSET_ELTS (src) >> -= realloc (EBITSET_ELTS (src), newsize * sizeof (tbitset_elt >> *

bitset: check memory allocation

Hi! Ok to push? commit 1fddc3eddd988829cd2b5b74dc3fab58a3093af8 Author: Akim Demaille Date: Thu Sep 5 11:36:39 2019 +0200 bitset: check memory allocation Reported by 江 祖铭 (Zu-Ming Jiang). https://lists.gnu.org/archive/html/bug-bison/2019-08/msg00016.html * lib

Re: maintainer-makefile: catch uses of $< in non-implicit rules

Hi Tim, Sorry I dropped the ball... > Reproducible everywhere (needs gawk being installed, else the > sc_prohibit_gnu_make_extensions is a no-op). Which is what I meant. So are you saying it work as (I) expected? > Akim, at least with GNU make 4.2.1 the combination of -q and -p doesn't > do wh

argmatch: adjust columns for help2man

t;fixit, diagnostics-parseable-fixits > show machine-readable fixes > >syntax-only > do not generate any file > >allall of the above > >none disable all of the above Cheers! commit ee77e5c1fef322b8c0a6596aa9b2c4

  1   2   3   4   5   >