Re: Forwarded: Segmentation Fault via recursive loop in Gawk

On 3/20/24 20:57, arn...@skeeve.com wrote: Note that I said EREs, which don't have to provide backreferences. Ah, sorry, I missed that. Thanks for correcting me. In that case there should be a polynomial-time solution.

Re: Forwarded: Segmentation Fault via recursive loop in Gawk

Note that I said EREs, which don't have to provide backreferences. Arnold Paul Eggert wrote: > On 3/20/24 01:40, arn...@skeeve.com wrote: > > It's possible to write a POSIX compliant matcher for EREs that doesn't > > have such problems; I know someone doing it. > > I think matching POSIX regula

[PATCH] gnulib-tool.py: Fix --extract-recursive-link-directive.

This patch fixes the failure of 'test-extract-recursive-link-directive-3.sh' in the gnulib-tool test suite: cmp: EOF on tmp529181-out which is empty --- ./test-extract-recursive-link-directive-3.output2024-03-20 19:16:08.842291576 -0700 +++ tmp529181-out 2024-03-20 19:17:56.295403277 -0

Re: gnulib-tool --extract-filelist whitespace diff fix

Hi Bruno, On 3/19/24 11:24 PM, Bruno Haible wrote: > It would be better to define a method getFiles_Raw -> str, > similarly to how getLicense_Raw is defined, and have > getFiles -> list > use that. Yes, that is a better idea. Here is a patch that does this. I beleive that this should match gnulib

Re: Forwarded: Segmentation Fault via recursive loop in Gawk

On 3/20/24 01:40, arn...@skeeve.com wrote: It's possible to write a POSIX compliant matcher for EREs that doesn't have such problems; I know someone doing it. I think matching POSIX regular expressions in polynomial time is equivalent to proving P=NP, i.e., you'll win the Turing Award if you

Re: Problems with directory trees "confdir-14B---" and "confdir3"

On 3/20/24 01:51, Peter Dyballa wrote: I was asking this myself: What is this test good for? It's possibly 15 years after it was introduced? If old glibc versions are no longer worth worrying about, a similar argument would apply to old Mac OS X versions, no?

[PATCH] gnulib-tool.py: Fix unconditional Automake snippets for non-tests.

This patch seems to be the proper fix for this diff from Emacs merge-gnulib: diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in index 6df7f6d9b00..49ca3229728 100644 --- a/lib/gnulib.mk.in +++ b/lib/gnulib.mk.in @@ -3296,7 +3296,9 @@ ifneq (,$(GL_COND_OBJ_STDIO_WRITE_CONDITION)) libgnu_a_SOURCES +=

Re: [PATCH] gnulib-tool.py: Prefer str.splitlines() over str.split('\n').

Hi Bruno, On 3/20/24 3:58 AM, Bruno Haible wrote: > * If an Automake snippet has a blank line, we want that blank line to be > preserved in the generated Makefile.am, not eliminated. Ah, okay I see. I agree that it is best to preserve whitespace here. I didn't see any '\v', '\f', etc. in the mo

Re: [PATCH] gnulib-tool.py: Prefer str.splitlines() over str.split('\n').

Hi Collin, > This patch changes calls of .split('\n') on string objects to > .splitlines(). ... > This should help reduce the amount of unexpected newlines in the > output of Makefiles and other generated files. I don't think this patch is appropriate: * splitlines() is documented to treat the '

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 67.

I wrote: > So, it's OK to undocument these options in gnulib-tool.sh. Done: 2024-03-20 Bruno Haible gnulib-tool.sh: Undocument the --[no-]cache-modules options. Reported by Collin Funk in . R

[PATCH] gnulib-tool.py: Prefer str.splitlines() over str.split('\n').

This patch changes calls of .split('\n') on string objects to .splitlines(). I think this is easier to read, but it also has a functional benefit: # With carriage returns print('1\n2\r3\r\n4\n'.split('\n')) ['1', '2\r3\r', '4', ''] print('1\n2\r3\r\n4\n'.splitlines()) ['1', '2', '3', '4'] # Or mo

Re: [PATCH] gnulib-tool.py: Don't emit empty Automake snippets.

Collin Funk wrote: > Apparently str.isspace() will return False for empty strings: > > print('\t'.isspace()) > True > print('\n'.isspace()) > True > print(''.isspace()) > False Oh, indeed. It's actually documented like this. > I've changed those conditions to the following: > >if (amsnippet

Re: Problems with directory trees "confdir-14B---" and "confdir3"

> Am 20.03.2024 um 05:38 schrieb Paul Eggert : > > ./configure gl_cv_func_getcwd_succeeds_beyond_4k=no I was asking this myself: What is this test good for? It's possibly 15 years after it was introduced? I am no person of MacPorts who can make decisions, more a user, but I'll suggest it to

Re: Forwarded: Segmentation Fault via recursive loop in Gawk

Hi. Paul Eggert wrote: > In glibc (and Gnulib) the regular-expression code has long been > maintained under the philosophy that the code cannot handle arbitrary > regular expressions. Any code that lets the user specify an arbitrary > regular expression is suspect, and this includes Awk scripts

Re: [PATCH] gnulib-tool.py: Don't emit empty Automake snippets.

Hi Bruno, On 3/19/24 3:00 AM, Bruno Haible wrote: > ... which tests whether the combination of the two snippets contains some > character that is not newline, not space, and not tab. I think I found the reason that these lines are printed. Apparently str.isspace() will return False for empty stri