> On 3 Feb 2021, at 03:45, Sam James wrote:
> [snip]
>> What's the result of
>> grep LIBCSTACK config.status
>> ? I.e. is GNU libsigsegv in use? And if yes, which version?
>
> # grep LIBCSTACK config.status
> S["LTLIBCSTACK"]=""
> S["LIBCSTACK"]=""
>
> So no, I think.
>
> I then installed GN
Hi,
> On 3 Feb 2021, at 03:23, Bruno Haible wrote:
>
> Hi,
>
Hey, thanks for the quick reply.
> What's the result of
> grep LIBCSTACK config.status
> ? I.e. is GNU libsigsegv in use? And if yes, which version?
# grep LIBCSTACK config.status
S["LTLIBCSTACK"]=""
S["LIBCSTACK"]=""
So no, I th
Hi,
> "FAIL: test-c-stack.sh
> =
>
> ./test-c-stack.sh: line 7: 3238828 Segmentation fault (core dumped)
> ${CHECKER} ./test-c-stack${EXEEXT} 2> t-c-stack.tmp
> FAIL test-c-stack.sh (exit status: 1)
>
> I didn’t get much particularly useful out of gdb yet:
What's the r
Hi,
This issue was noticed through grep 3.5 and 3.6’s stack-overflow test failing
[0] on SPARC on Gentoo GNU/Linux.
Following Paul Eggert’s instructions in that bug to test gnulib’s c-stack
component, I had the following
in /gltests/test-suite.log:
"FAIL: test-c-stack.sh
=
This patch replaces the internal fnmatch pattern list generation
to use a dynamic array.
Checked on x86_64-linux-gnu.
---
posix/fnmatch.c | 24 +-
posix/fnmatch_loop.c | 190 +++
2 files changed, 87 insertions(+), 127 deletions(-)
diff --git a/po
Gnulib has added the proposed fix with aed23714d60 (done in 2005), but
recently with a glibc merge with 67306f6 (done in 2020 with sync back)
it has fallback to old semantic to return -1 on in case of failure.
>From gnulib developer feedback it was an oversight. Although the full
fix for BZ #1418
