gcc warnings in grep snapshot

t differ in signedness ... Suggestion: add a cast. Find attached a patch that solves all the warnings except for the broken check_multibyte_string. Bruno 2009-01-23 Bruno Haible * lib/posix/regex.h (__restrict, __restrict_arr): Remove macros. (_Restrict_, _Restrict_arr_): New macros. Fr

Re: upstream regex

[CCing bug-gnulib. This is a reply to ] Hello Tony, > > Suggestion: Use the same logic for restrict and restrict_arr as in > > gnulib/lib/regex.h. > > What is considered the authoritative source of regex.h? Is it the glibc > sou

Re: test-fcntl-h-c++.cc:32: error: 'open' is not a member of 'gnulib'

Jim Meyering wrote on bug-gnulib: > Fedora 12, gcc-c++-4.4.3-4.fc12.x86_64 > > FYI, I pushed the grep changes, so if you get the latest, > revert the latest bootstrap.conf change (which avoids the > failing test), then ./bootstrap && ./configure etc. should > demonstrate the failure. I checked ou

need for fcntl

Hi Jim, Seeing this commit: http://git.savannah.gnu.org/gitweb/?p=grep.git;a=commitdiff;h=3f6b7379652bb1d9a6ebc02134d64172d82a669d If you need , the right gnulib module is 'fcntl-h'. The module 'fcntl' provides the fcntl() function, which you don't need here, AFAICS. Bruno

Re: [PATCH] build: avoid link failure on systems using gnulib's fcntl but not open

Jim Meyering wrote: > I noticed this build failure for grep: > > http://hydra.nixos.org/build/329919 > > CCLD grep > Undefined symbols: > "_rpl_open", referenced from: > _grepfile in grep.o > ld: symbol(s) not found > collect2: ld returned 1 exit status >

Re: [PATCH] build: avoid link failure on systems using gnulib's fcntl but not open

Jim Meyering wrote: > in that situation it would be nice to have a way > to ensure that the primary module list is a superset of > those used for the tests. In general, you don't want this. Let's take this precise example: Your program needs 'dup2'. We decided to make a test for dup2 which happens

Re: test-fcntl-h-c++.cc:32: error: 'open' is not a member of 'gnulib'

Hi Jim, > I am ambivalent about pkg-config, and cannot justify > its use in grep, but will wait until after 2.6 to remove it. I wasn't asking to remove pkg-config, but only to distribute the complete source code of aclocal.m4, excluding released versions of Automake. So that anyone can rebuild ac

Re: [PATCH] build: avoid link failure on systems using gnulib's fcntl but not open

.c:#if GNULIB_MKOSTEMP mkstemp-safer.c:#if GNULIB_MKOSTEMPS mkstemp-safer.c:#if GNULIB_MKSTEMPS realloc.c:#if GNULIB_MALLOC_GNU && !defined malloc realloc.c:#if GNULIB_REALLOC_GNU && !NEED_REALLOC_GNU && !SYSTEM_MALLOC_GLIBC_COMPATIBLE save-cwd.c:#if GNULIB_FCNTL

Re: [PATCH] build: avoid link failure on systems using gnulib's fcntl but not open

mkostemps:gl_MODULE_INDICATOR_FOR_USE([mkostemps]) modules/mkstemps:gl_MODULE_INDICATOR_FOR_USE([mkstemps]) This will be addressed in the next patch. 2010-03-27 Bruno Haible Distinguish two kinds of module indicators. * m4/gnulib-common.m4 (gl_MODULE_IN

Re: [PATCH] build: sync primary and tests-related gnulib module lists

Jim Meyering wrote: > * bootstrap.conf (gnulib_modules): Synchronize the primary list > of modules with the list used by tests, so that we don't have > a repeat of the wctob-vs-Solaris 8 build failure. You should now be able to revert this. The bug is fixed in gnulib since yesterday. Bruno

Re: [PATCH] Avoid polluting cygwin namespace.

Hi Eric, >cygwin*) > FAULT_CONTEXT='CONTEXT' > -FAULT_CONTEXT_INCLUDE='#include ' > +# CONTEXT is defined in , but cygwin programs should not > +# normally inspect the contents of CONTEXT, and the outright inclusion > +# of pollutes the namespace. > +FAULT_CONTEXT_INC

Re: [PATCH] Avoid polluting cygwin namespace.

Eric Blake wrote: > >error: redefinition of typedef ‘CONTEXT’ > > That can be worked around; here's an alternative approach: > > FAULT_CONTEXT='struct _CONTEXT' > FAULT_CONTEXT_INCLUDE='struct _CONTEXT; /* include to see inside > */' Yes, this would fix the first problem. > > 2) The users

EGexecute: don't assume buffer ends in a newline

e that is not present. This fixes it for me, and causes no regressions in grep's testsuite. For your review. I don't have write access to the 'grep' repository, but have a copyright assignment for 'grep' in place. 2010-05-23 Bruno Haible EGexecute: Don&

EGexecute: avoid access beyond end of buffer

) match[len]) is only valid if &match[len] < end - 1 <==> buf + start + len < end - 1 <==> start + len < end - buf - 1 The previous test len < end - beg - 1 is wrong because match may be != beg or equivalently start may be != beg -

Re: EGexecute: don't assume buffer ends in a newline

Hi Paolo, > > /* If we've made it to this point, this means DFA has seen > >a probable match, and we need to run it through Regex. */ > > - best_match = end; > > + best_match = end + 1; > > Shouldn't this be > >best_match = end + (end < buflim); > > ? No. You

Re: EGexecute: don't assume buffer ends in a newline

Jim Meyering wrote: > ... it no longer applies due to changes in dfasearch.c. > > Would you please update the patch? Here is the update. It passes "make check". 2010-08-17 Bruno Haible EGexecute: Don't assume the buffer ends in a newline. * sr

grep-2.7: build failure on systems with libiconv

m does not use $(LIBICONV). Here is a fix. $(LIBICONV) should be at the end of LDADD. Note that after applying this fix, I had to update src/Makefile.in by hand, because the automake/autoconf machinery refused to update anything, because the version of automake with which the release was packa

Re: character ranges in regular expressions

Paolo, > Bruno, ... Can you shed light on what __collseq_table_lookup is supposed > to mean? It is a runtime lookup function into a table that maps Unicode characters to uint32_t values. For a 'char' value, the most efficient way to implement a mapping from 'char' to uint32_t is through an array

Re: character ranges in regular expressions

Paolo, > Yes, this is what I'm curious about. Why does the table have the > order A..Za..z for en_US.UTF-8 and aAbB...yYzZ for cs_CZ.UTF-8, even > though strcoll uses the latter in both locales? I don't know. But what is the "correct" result in the first place? On my glibc-2.8 system I have a

Re: character ranges in regular expressions

Paolo Bonzini wrote: > > What is the correct result for 'grep' and for regex? (I assume it's the > > same for both, since both are specified by POSIX.) > > Unfortunately POSIX only (implicitly) specifies that the two have to be > consistent, but the exact result is unspecified. Indeed:

Re: [bug #31646] grep fails to build on Solaris 10, because it lacks grep

Hi Jim, > - dnl Work around a bug of AC_EGREP_CPP in autoconf-2.57. > - AC_REQUIRE([AC_PROG_CPP]) > - AC_REQUIRE([AC_PROG_EGREP]) > - >AC_CACHE_CHECK([whether defines strtoimax as a macro], > gl_cv_func_strtoimax_macro, > [AC_EGREP_CPP([inttypes_h_defines_strtoimax], [#include

Re: [bug #31646] grep fails to build on Solaris 10, because it lacks grep

Jim Meyering wrote: > While the dependency of AC_EGREP_CPP on AC_PROG_EGREP > is unavoidable, there are others that are indeed unnecessary, > since they serve only to work around a bug in autoconf-2.57, > which is no longer relevant, since we (gnulib-tool) now > requires 2.59 or newer. > ... > Now

Re: [bug #31646] grep fails to build on Solaris 10, because it lacks grep

Hi Jim, > The proposed patch is solely clean-up on the gnulib side. > As the subject implies, initially I thought this was the solution > to the grep-configure problem. As a pure clean-up patch, it is OK. But you confused me completely by proposing it under the subject "grep fails to build on Sol

Re: [bug #31646] grep fails to build on Solaris 10, because it lacks grep

Paolo Bonzini wrote: > +# Override grep during configure. > +fn_grep () { I would suggest more comments. - What is the purpose of this override? - What are its limitations? 10 years from now, no one will remember. Suggestion: # Set the GREP and EGREP variables to a dummy replacement for the

Re: Dealing with character ranges in grep

Paolo, > > [=e=] to match "e" as well as accented versions like é, è and ê). > > That is the one feature that you get with glibc, and that you would > > sacrifice when building --with-included-regex. > > I agree.  It's up to distros to choose, of course. If you are on the point of sacrificing a

Re: Dealing with character ranges in grep

Paolo, > With my proposal, distros/people that use --with-included-regex would > get understandable semantics + no equivalence classes > ... > locale behavior of regex are irremediably > broken. For example, when you have a collation element, you can match > it using ranges (e.g. [d-i] matches

Re: implementing extended bracket expressions in gnulib [was Re: Dealing with character ranges in grep]

Paolo, > My proposal wouldn't change defaults, which is why I believe that this > is a separate topic. But at the same time you are pushing for the use of --with-included-regex. We found out that by doing this, the equivalence classes feature gets lost, and the divergence between glibc and gnuli

Re: the release of grep-2.9 is imminent

Jim Meyering wrote about modifications done to .gitignore files: > I've Cc'd bug-gnulib, since gnulib-tool appears > to be doing it. > > I notice that some of your differences appear to be due to sorting > with a different locale than I use. That implies there's a second > problem: perhaps one of

meaning of backslash single-quote?

Hi, GNU grep (I tested versions 2.5, 2.7, 2.9) appears to assign a meaning to the backslash single-quote character sequence in the argument that ought to be a Basic Regular Expression. $ grep --version grep (GNU grep) 2.9 ... $ echo ' abc" ' | grep "\"\\'" $ echo ' abc"' | grep "\"\\'" abc" The

Re: meaning of backslash single-quote?

Paolo Bonzini wrote: > > As a quality of implementation issue, I would prefer to get an error message > > for such an undefined BRE. > > I don't think this is a good idea. How about documenting it, then? > It's end-of-buffer, together with \` for beginning of buffer. It makes > a difference fr

grep-2.9.69-f91c on Linux/SPARC

On Linux/SPARC 64-bit, glibc 2.6.32: FAIL: empty FAIL: fgrep-infloop FAIL: in-eq-out-infloop Find attached the log file. -- In memoriam Jan Opletal linuxsparc64.log.gz Description: GNU Zip compressed data

grep-2.9.69-f91c on OSF/1

On OSF/1 5.1: "make" succeeds, but "make check" fails: $ make check No suffix list. Making check in po Making check in lib make check-recursive Making check in doc Making check in src Making check in tests make get-mb-cur-max `get-mb-cur-max' is up to date. make check-TESTS sh: VERSION=2.9.69-

grep-2.9.69-f91c testing

Test results: * Linux x86_64 / glibc 2.11 * Linux IA-64 * Linux HP-PA * Linux MIPS * Linux PowerPC * NetBSD 5.1 * IRIX 6.5 * OpenBSD 4.6 SPARC All tests passed. * MacOS X 10.5 * FreeBSD 6.4 * OpenBSD 4.9 XPASS: word-delim-multibyte * Solaris 7 XPASS: turkish-I * AIX 5.1 * HP-UX 11.00 * HP-UX

Re: grep-2.9.69-f91c on MSVC 9

> * MSVC 9 > > Compilation failure: Once this compilation failure is fixed, more compilation failures (due to syntax errors) occur in dfa.c:822 dfa.c:3426 kwsearch.c:43 kwsearch.c:110 main.c:2146 It's an ISO C99 vs. ANSI C issue (declaration after statement). Also, in pcresearch.c the

hardcoded /bin/bash

tests/fedora uses /bin/bash, which may not exist. How about this patch? Tested on MacOS X, FreeBSD, OpenBSD, NetBSD, AIX, HP-UX, IRIX, OSF/1, Solaris. 2011-11-11 Bruno Haible Don't assume that /bin/bash exists. * tests/fedora: Run using /bin/sh, not /bin/bash. diff

Re: grep-2.9.69-f91c on OSF/1

from the Makefile. > I would much rather recommend that work-around than pessimize all > "make check" rules like that -- and just for a few old, losing systems. It's a lot of prerequisiste work to have to install bash and GNU make, for being able to install GNU grep. Past these two

Re: grep-2.9.69-f91c on OSF/1

7;\\201'" | od -t x1 000 81 001 While at it, let me also fix a bashism (while avoiding backslashes inside backquote). I've tested this fix: 2011-11-11 Bruno Haible Fix high-bit-range test failure on OSF/1 5.1. * tests/high-bit-range: Use octal escape ins

Re: grep-2.9.69-f91c on MSVC 9

rning with --disable-perl-regexp --enable-gcc-warnings. 2011-11-11 Bruno Haible Fix compilation error on MSVC 9 to due Pexecute() declaration. * src/pcresearch.c (WITHOUT_PCRE_NORETURN): Remove macro. (Pexecute): Replace abort() call with code that does not trigger GCC

Re: grep-2.9.69-f91c on OSF/1

Eric Blake wrote: > The grep test framework is borrowing > from gnulib's tests/init.sh, which should already be re-exec'ing under a > shell that supports $(). Ah, right. Here's a simpler patch then. 2011-11-11 Bruno Haible Fix high-bit-range t

Re: grep-2.9.69-f91c on Linux/SPARC

Jim Meyering wrote: > > On Linux/SPARC 64-bit, glibc 2.6.32: > > > > FAIL: empty > > FAIL: fgrep-infloop > > FAIL: in-eq-out-infloop > > So far I've looked only at the last one. > That test is designed to ensure that grep detects > when its input file is the same as its output. > That it is failin

Re: grep-2.9.69-f91c on OSF/1

Jim Meyering wrote: > +it is probably because you are using non-GNU-make with an old /bin/sh. If > so, sed 's/with an old/or an old/ The workaround is to use GNU make *and* a different SHELL. Bruno -- In memoriam Nicholas Owen

Re: grep-2.9.69-f91c on OSF/1

Jim Meyering wrote: > > 2011-11-11 Bruno Haible > > > > Fix test suite execution failure on OSF/1 5.1. > > * tests/Makefile.am (TESTS_ENVIRONMENT): Use only the portable form of > > the 'export' shell built-in. > > Thanks, but I&

Re: failure in building gnulib tests wih pcc on debian

Eric Blake wrote: > > ... on an unstable Debian using pcc > > (Portable C Compiler, version 1.1.0~DEVEL+20110422-1 > ... > Warnings like this, and the error in test-float.c, mean that all other > packages using the same gnulib modules will have the same problem. We > should fix it upstream in gnul

Re: grep-2.10 testing (was: grep-2.9.69-f91c testing)

For the record, here are the test results with grep-2.10: > * MacOS X 10.5 > * FreeBSD 6.4 > * OpenBSD 4.9 > > XPASS: word-delim-multibyte Unchanged in grep 2.10. > * Solaris 7 > > XPASS: turkish-I Unchanged. > * AIX 5.1 > * HP-UX 11.00 > * HP-UX 11.11 > * Solaris 8 > * Solaris 9 > > All gr

grep-2.10 on OSF/1

x27;t. (My assessment that the SHELL variable needed to be changed [1] was apparently wrong.) In 2.10, the situation is the same. Whereas the patch I had proposed in [2] made "make check" pass. The next patch [3] was OK as well. The commit af8be8854b7719aea3c194a2dfbfce6c37d646f6, howev

Re: grep-2.10 testing

Hi Jim, > Stepping through that test [word-delim-multibyte] manually, > (and what I should have done in the first place) > I see this: > > openbsd$ e_acute=$(printf '\303\251') > openbsd$ echo "$e_acute" > in || framework_failure_ > openbsd$ LC_ALL=en_US.UTF-8 > -bash: warning: se

Re: grep-2.10 testing

Hi Jim, > diff --git a/src/dfa.c b/src/dfa.c > index e28726d..8f79508 100644 > --- a/src/dfa.c > +++ b/src/dfa.c > @@ -1071,8 +1071,18 @@ parse_bracket_exp (void) >return CSET + charclass_index(ccl); > } > > +/* Add this to the test for whether a byte is word-constituent, since on > + BSD-

new module 'isatty' (was: Re: MS-Windows build of Grep [2/4])

idea. > it is a little bit more complicated due to INVALID_HANDLE exception > raising in _get_osfhandle(fd) but the idea I think that in this case _isatty(fd) will already return 0. I'm adding this new module. Feel free to use it in 'grep'. 2012-01-02 Bruno Haible

Re: new module 'isatty'

this additional patch, - to fix a test failure on MSVC 9, - to fix the two wrong comments. Bruno 2012-01-03 Bruno Haible isatty: Support for MSVC 9. * doc/posix-functions/isatty.texi: Mention the MSVC problem. * lib/isatty.c: Include , msvc-inval.h. (_isatty_

Re: new module 'isatty'

Eli Zaretskii wrote: > > Because that would yield warnings when you compile on mingw with "-Wall". > > I compiled with -Wall (using intptr_t) and didn't have any warnings. > Maybe you are using a newer (= more pedantic) version of GCC. Maybe I misremembered, and it was MSVC which gave the warning

Re: Building grep 2.9 on SunOS 4

Eric Blake wrote: > Gnulib would be the place to fix this, but right now, gnulib has pretty > much abandoned SunOS 4 as a museum piece Yup. For more info about gnulib's coverage of target platforms, see the documentation section here:

Re: [platform-testers] new snapshot available: grep-2.11.11-b00d1

Jim Meyering wrote: > grep snapshot: > http://meyering.net/grep/grep-2.11.11-b00d1.tar.xz On Linux/glibc systems with various CPUs: All tests passed. On OpenBSD 4.9: All tests passed. On Solaris 11 2011-11: All tests passed.

Re: [platform-testers] new snapshot available: grep-2.11.11-b00d1

> > grep snapshot: > > http://meyering.net/grep/grep-2.11.11-b00d1.tar.xz Some more test results: HP-UX 11.00: All tests passed. IRIX 6.5: All tests passed. OSF/1 5.1: All tests passed. Solaris 9, 10: All tests passed.

[bug #21458] Rename norwegian locale/translation

Follow-up Comment #1, bug #21458 (project grep): This has to be decided by the TP and the Norwegian translation team inside the TP. Please write to the TP coordinator [coordinator at translationproject period org] and to the Norwegian Bokmal team [i18n-nb at lister period ping period uio period n

bug#25146: grep unusable on mingw - SAME_INODE woes

> grep snapshot: > http://meyering.net/grep/grep-ss.tar.xz 1.4 MB > http://meyering.net/grep/grep-ss.tar.xz.sig > http://meyering.net/grep/grep-2.26.39-ae3f.tar.xz This release, built for mingw, is hardly usable: - 33 out of 107 tests fail, - A simple "grep.exe o xx > yy" fails with

bug#25146: grep unusable on mingw - SAME_INODE woes

> I installed the attached patch into Gnulib. This > isn't perfect (it means MinGW grep won't detect that the input and > output are the same file), but it should be good enough to fix the > glaring bugs and to conform to POSIX. Thanks, Paul. Yes, it surely fixes the immediate issue. I agree.

bug#22357: grep -f not only huge memory usage, but also huge time cost

Trevor Cordes wrote: > I've read in numerous places (O'Reilly books mostly) that grep or pcre > is often/sometimes faster than fgrep, so I think it is (somewhat) common > knowledge and I wouldn't worry too much about that perception. It is wrong to put the burden of the algorithm choice on the use

bug#22357: grep -f not only huge memory usage, but also huge time cost

Hi Paul, > Before installing anything like that, I'd first like to look into improving > the > DFA performance, along the lines suggested by Norhiro Tanaka. Part of the > problem appears to be that position-set merging, even with his latest > proposed > changes, is O(N**2) where N is the patt

bug#25821: grep-3.0 FAILS on Make phase

t. Fixed in gnulib as follows: 2017-02-21 Bruno Haible lock tests: Fix build failure on GNU/Hurd (regression from 2017-01-05). Reported by Rene Saavedra in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25821 via Paul Eggert. * lib/g

bug#27532: getprogname: support for qemu

Hi, When running the testsuite of grep-3.0 with qemu user mode, some tests fail. How to reproduce: - On a Debian or Ubuntu system, install package 'g++-5-aarch64-linux-gnu'. - Install qemu-2.8.1 or qemu-2.9.0 from source. - Prepare for executing aarch64 binaries: $ sudo update-binfmts --install

bug#27532: grep test failures under qemu

Oops, the title was wrong. Corrected subject: "grep test failures under qemu"

bug#27532: getprogname: support for qemu

Hi Jim, > Does this patch solve the problem? Yes, this patch fixes the filename-lineno.pl failure. Thanks. There are 3 similar failures, still. Logs are attached. Bruno in-eq-out-infloop.log.gz Description: application/gzip + initial_cwd_=/tmp/grep-3.0/build-arm64/tests + fail=0 + testdir_pre

bug#27532: getprogname: support for qemu

Hi Jim, > Here's a patch that should address those others, too. Can you confirm > that it fixes those problems? Yes, with this patch, all 4 failures are gone, and "make check" proceeds to the gnulib tests, which also all succeed. Bruno

bug#39206: warning in lib/unistr/u8-uctomb.c

onfiguration determined that the compiler does not support the 'inline' keyword. Since the compiler is clang, this finding is not true. Most likely, you had -Werror in $CC $CFLAGS already during configuration time. This is NOT SUPPORTED, since it causes many configure tests to produce wron

bug#40868: Grep C library for multi-string pattern matching?

> Does Grep provide a library that exposes its multi-string pattern > matching? If not, can someone recommend an implementation? I don't know exactly what you mean, but the GNU grep algorithms are used as a library in GNU gettext: https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=tree;f=gett

bug#50098: Configuring --with-libsigsegv results in link error

hich > I fixed in Gnulib by installing the attached. Thanks. It was my mistake from 2021-05-18; sorry. This patch refactors the macros a bit, so that the test for libsigsegv is only performed once, not twice. --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2021-08-21 Bruno Haible + +

bug#50098: Configuring --with-libsigsegv results in link error

Evan Miller wrote: > > Oh, I see you're building for an old system (Mac OSX 10.4.11, circa 2007) > > that Apple itself is no longer supporting. Although we don't normally worry > > about such platforms, perhaps you can come up with a patch that clearly > > won't break mainline platforms. > > A

bug#51144: GNU grep 3.7 fails to build on FreeBSD

Alexey Dokuchaev wrote in and : > > >Ports framework does several things which affect GNU configure > > >scripts, particularly, it replaces build-aux/config.guess file > > >wi

bug#51144: GNU grep 3.7 fails to build on FreeBSD

Alexey Dokuchaev wrote: > I wonder why it's not in our template if it's from 2003. Just guessing: Maybe because some kernel-related FreeBSD packages want 'amd64'? In other words, don't you need to distinguish original FreeBSD packages from other packages? Bruno

bug#64235: patch: Ensure that makeinfo ≥ 6.8 checks the @menu structure

e grep.info V=1) and make sc_makefile_at_at_check From 394ad4fb9b1c9f565e3f07b187950be13758df7a Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Fri, 23 Jun 2023 00:48:13 +0200 Subject: [PATCH] =?UTF-8?q?build:=20Ensure=20that=20makeinfo=20=E2=89=A5?= =?UTF-8?q?=206.8=20checks=20the=20@menu=20structu

bug#71468: backref-multibyte-slow test fails on Cygwin

Building the current grep (git master) with the current Gnulib on Cygwin 3.5.3, I see a test failure: FAIL: backref-multibyte-slow The detailed log is attached. Bruno log.gz Description: application/gzip

bug#71470: test failure on CentOS 7

01975ff Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Mon, 10 Jun 2024 13:30:49 +0200 Subject: [PATCH] maint: Remove special optimization for CentOS 7. * configure.ac (gl_cv_func_mbrtowc_empty_input): Don't set. * bootstrap.conf (avoided_gnulib_modules): Remove mbrtowc-tests. --- boo

bug#71471: case-fold-titlecase test fails on OpenBSD

Building the current grep (git master) with the current Gnulib on OpenBSD 7.5, I see a test failure: FAIL: case-fold-titlecase Here is the detailed log. FAIL: case-fold-titlecase = é --- out

bug#71470: test failure on CentOS 7

Paul Eggert wrote: > I installed the 2nd patch. I confirm that "make check" now passes on CentOS 7. Bruno

bug#71470: test failure on CentOS 7

Paul Eggert wrote on 2024-06-11: > Close call, but since CentOS 7 is still > officially alive I installed the 2nd patch. CentOS 7 will be supported until 2028. I've updated Gnulib's end-of-life.txt: https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=end-of-life.txt;h=15e2c6cca

bug#71995: fmbtest unnecessarily skipped on FreeBSD

work portably for ages; see https://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=tree;f=libcharset/tools;h=f756e65e5ea8fef47afc8bb7ae1094e169012c78;hb=HEAD >From a4501af35dcc7603ee5f500aa87aafe577958010 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Mon, 8 Jul 2024 14:06:16 +0200 Subject: [PATCH] tests: Fix

bug#77613: grep-3.11.69-a4628 on GNU/Hurd

Hi Jim, > > So, IMO, there are two bugs: > > > > 1) When the allocation of the kwset takes more memory than available, > > 'grep' should exit via xalloc_die(), instead of waiting to be killed > > by the OOM killer. > > > > 2) In the 'hash-collision-perf' unit test: The use of a perl

bug#77613: grep-3.11.69-a4628 on GNU/Hurd

Jim Meyering wrote: > Thanks again. This one should do it: skipping the test in that case. Yes, this one does it. Now "make check" proceeds through all tests. No failure. Bruno

bug#77654: fix module name in bootstrap.conf

In the logs of running 'bootstrap' in grep I see this line: gnulib-tool: warning: module realloc-gnu-h doesn't exist There is no such module 'realloc-gnu-h'. This line was introduced in commit 006951de68dffb7a4a0f27fdd6a1a6290cd53d5e on 2025-02-01. Module 'realloc-gnu' in Gnulib is deprecated,

bug#77613: grep-3.11.69-a4628 on GNU/Hurd

Jim Meyering wrote: > Oh! Sorry. I made only the final invocation use the timeout. Must use > it in the loop, too. > Here's a better patch: The 'hash-collision-perf' test still hangs both of my GNU/Hurd machines. One of the machines now says: vm_page warning: unable to recycle any page Th

bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

Pádraig Brady wrote: > bs=0 > ws=4095: printf: write error > ws=4096: printf: write error > ws=4097: printf: write error > bs=4096 > ws=4095: printf: write error: No space left on device > ws=4096: printf: write error > ws=4097: printf: write error > bs=8192 > ws=4095: printf: w

bug#77613: grep-3.11.69-a4628 on GNU/Hurd

On - GNU/Hurd x86_64 from 2024, - GNU/Hurd i386 from 2023, I see a test hang: hash-collision-perf. On GNU/Hurd x86_64: When I interrupted the build, the file 'in' has 512 lines, and find attached the log file of this test. As you can see, the value of small_ms stays 0 even for larger file

bug#71468: backref-multibyte-slow test fails on Cygwin

Hi Collin, > The issue here seems to be a carriage return emitted by Perl generated > in these lines: > > + gawk 'BEGIN {for (i=0; i<13000; i++) print "aba"}' /dev/null > ++ LC_ALL=C > ++ perl -le 'use Time::HiRes qw(time); my $s = time(); > system q,grep -E '\''^([a-z]).\1$'\'' in