gcc warnings in grep snapshot

attached a patch that solves all the warnings except for the broken check_multibyte_string. Bruno 2009-01-23 Bruno Haible br...@clisp.org * lib/posix/regex.h (__restrict, __restrict_arr): Remove macros. (_Restrict_, _Restrict_arr_): New macros. From gnulib/lib/regex.h. (regcomp, regexec

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

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 make[2]:

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

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

!SYSTEM_MALLOC_GLIBC_COMPATIBLE save-cwd.c:#if GNULIB_FCNTL_SAFER stdio-write.c:#if GNULIB_SIGPIPE write.c:#if GNULIB_SIGPIPE 2010-03-27 Bruno Haible br...@clisp.org Avoid side effects from tests-related modules on the compilation of lib. * m4/gnulib-common.m4

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

/mkstemps:gl_MODULE_INDICATOR_FOR_USE([mkstemps]) This will be addressed in the next patch. 2010-03-27 Bruno Haible br...@clisp.org Distinguish two kinds of module indicators. * m4/gnulib-common.m4 (gl_MODULE_INDICATOR_FOR_TESTS): Renamed from gl_MODULE_INDICATOR

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 windows.h' +# CONTEXT is defined in windows.h, but cygwin programs should not +# normally inspect the contents of CONTEXT, and the outright inclusion +# of windows.h pollutes the namespace. +

EGexecute: avoid access beyond end of buffer

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 - buf. Bruno 2010-05-24 Bruno Haible br...@clisp.org

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 br...@clisp.org EGexecute: Don't assume the buffer ends in a newline. * src/dfasearch.c

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 inttypes.h defines strtoimax as a macro], gl_cv_func_strtoimax_macro, [AC_EGREP_CPP([inttypes_h_defines_strtoimax],

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 we

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

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

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 gnulib

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 regular

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 http://en.wikipedia.org/wiki/Jan_Opletal linuxsparc64.log.gz Description: GNU Zip compressed data

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 *

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 br...@clisp.org Don't assume that /bin/bash exists. * tests/fedora: Run using /bin/sh, not /bin/bash

Re: grep-2.9.69-f91c on OSF/1

-exclude5.sh). I'll let others worry about these failures. Then here's a proposed patch. 2011-11-11 Bruno Haible br...@clisp.org 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

Re: grep-2.9.69-f91c on OSF/1

a bashism (while avoiding backslashes inside backquote). I've tested this fix: 2011-11-11 Bruno Haible br...@clisp.org Fix high-bit-range test failure on OSF/1 5.1. * tests/high-bit-range: Use octal escape instead of hexadecimal escape sequence. Avoid $(...) syntax

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 br...@clisp.org Fix high-bit-range test failure on OSF/1 5.1

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

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 http://en.wikipedia.org/wiki/Nicholas_Owen_(martyr)

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 gnulib. I

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

grep-2.10 on OSF/1

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, however, broke it. Here is a fix: 2011-11-20 Bruno Haible br

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

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

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 br...@clisp.org New module 'isatty'. * lib/unistd.in.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 warnings.

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#25821: grep-3.0 FAILS on Make phase

n gnulib as follows: 2017-02-21 Bruno Haible <br...@clisp.org> lock tests: Fix build failure on GNU/Hurd (regression from 2017-01-05). Reported by Rene Saavedra <ren...@openmailbox.org> in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25821 via Paul Egger

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

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

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 +

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

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

on 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 wrong results. 202

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:

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

xed 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 + + c-stac

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

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

o 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=20structure.?= MIME