Re: [PATCH v2] grep: remove --mmap

Paolo Bonzini writes: > mmap is a bad idea for sequentially accessed file because it will cause > a page fault for every read page. That would not be true if grep used posix_madvise with the POSIX_MADV_SEQUENTIAL option, right? Shouldn't this should be tried out before removing the use of mmap?

Re: removing blank lines: "grep ." is really slow

Paolo Bonzini writes: > On 04/18/2010 06:32 AM, Ivan wrote: >> So... right now, "." means "valid UTF-8 character"? Or not? > > Yes, if your locale is UTF-8. Wouldn't it be better to model encoding errors as characters? That is, if grep sees a byte that cannot possibly be the start of a characte

Re: Regular expressions with high or nested repetition counters

Dag Hovland writes: > http://hdl.handle.net/1956/3628 > http://www.ii.uib.no/~dagh/fac/ > I wondered if you are interested in having this kind of functionality in > GNU grep? Yes, we're always interested in performance improvements, and this one looks like it'd be a substantial one. > Note tha

Re: [PATCH] dfa: fix signedness warnings

On 05/21/10 00:20, Paolo Bonzini wrote: > - prepare_wc_buf (p, end); > + prepare_wc_buf ((const char *)p, end); A better fix, in the long run anyway, is to remove the part of the code that casts char * to unsigned char *, and to use char * uniformly. The trick of casting char * to unsi

Re: [PATCH 1/3] grep: add --warnings={always,never,auto}.

On 08/27/2010 03:56 AM, Paolo Bonzini wrote: > On 08/27/2010 12:13 PM, Jim Meyering wrote: >> I have a fundamental aversion to making functionality like this new >> warning depend on whether a standard input or output stream is a >> TTY. >> Personally, I want my script to fail if I u

Re: [patch #6569] Allow grep to work in small stack environment

On 08/27/2010 01:39 AM, Jim Meyering wrote: > - use xnmalloc, not malloc+test+return, so we don't ignore malloc failure. > - use sizeof *VAR, not "sizeof TYPE" -- the former is more maintainable. > - adjust indentation to retain declaration alignment There are many places in other GNU apps,

Re: [patch #6569] Allow grep to work in small stack environment

On 08/27/2010 12:33 PM, Eric Blake wrote: > 4k in a non-recursive algorithm is probably fine for a non-threaded app; Yes, and that is the case here. > but if there is any chance for recursion, then stack-allocating a 4k > array risks interfering with stack overflow detection Yes, quite right; I

Re: [PATCH 1/3] grep: add --warnings={always,never,auto}.

On 08/30/10 00:47, Paolo Bonzini wrote: > It's true that the GNU coding standards say "please don't make the > behavior of the program depend on the type of output device it is used > with". On the other hand they also say "Compatibility requires certain > programs to depend on the type of output

Re: have you ever mistyped [[:lower:]] as [:lower:] ?

On 09/01/2010 07:25 AM, Eric Blake wrote: > Personally, I'd _like_ to try to get POSIX to allow unspecified behavior > for a bracket expression that starts and ends with colon, Likewise. Thanks for starting the Aardvark at . I was amused to see that,

Re: [PATCH 2/2] tests: add testcase for previous fix

On 09/23/10 04:52, Paolo Bonzini wrote: > Or better, we're at glibc's mercy: > > $ LC_ALL=cs_CZ.UTF-8 devel/grep/+build/src/grep -E '[A-Z]' in > 00a > 00g > 00A > 00G > 00Z > > Yay for yet another definition of range expressions. Can we fix things so that we're not at glibc's mercy, even there?

Re: character ranges in regular expressions

On 09/24/10 14:52, Bruno Haible wrote: > For other people, the locale dependent behaviour is useful, that is, 51 is > desired. I'm skeptical. In my experience, it is universally considered a misfeature that in some implementations and locales, [A-Z] matches some (but not all!) lower case charact

Re: Run-time dynamic linking in grep

On 01/21/2011 05:44 AM, Reuben Thomas wrote: > To try to avoid duplicated work, I'll start with one. Attached, a > rebased patch for adding transparent decompression using zlib (this is > patch #7017). Dumb question. Won't this have bad performance on multicore machines, compared to doing the dec

Re: Run-time dynamic linking in grep

On 01/21/2011 11:16 AM, Reuben Thomas wrote: >> Won't this have bad performance on multicore machines, >> > compared to doing the decompression in a separate process? > If it does, you can do the decompression in a separate process. Sorry, I don't follow. In the common case where I'm doing a 'gre

Re: update to latest gnulib and clean-up

On 04/28/11 01:52, Jim Meyering wrote: > These changes fix typos, add explicit "extern" keywords > (preparing for...) What does that "..." stand for? (Sorry, I don't remember the justification for explicit "extern".)

Re: update to latest gnulib and clean-up

On 04/28/11 14:11, Jim Meyering wrote: > If the two lists don't match (modulo heuristics), then that's > a syntax-check failure. Hmm, maybe I should try that out with Emacs too. What I currently do with Emacs is a bit different. For each file emacs/src/FOO.c, I look for symbols that FOO exports

Re: Dealing with character ranges in grep

On 06/08/2011 10:14 PM, Aharon Robbins wrote: > So, for the upcoming gawk 4.0, I decided (as Karl put it) to cut the > Gordian knot and make ranges behave like the C locale, the way it's long > been documented, and as most people expect. Those who want the POSIX > behavior can still get it using

Re: [BUG] grep cannot handle large lines

On 06/09/11 15:23, Nadeem Bulsara wrote: > I have a file which has millions of characters in one single line. Grep is > unable to detect patterns beyond a certain length. Is there a threshold ? There is not supposed to be a limit, other than memory. Can you give a simple example that illustrates

Re: Dealing with character ranges in grep

On 06/15/11 10:00, Aharon Robbins wrote: > Can I get a clear "yes, grep and sed are going to change to Reasonable > Range Interpretation"? I can't speak for grep and sed since I'm not a maintainer of either, but to my mind the only thing that makes sense is for regular expressions like [a-z] to ha

Re: [PATCH] dfa: don't overrun a malloc'd buffer for certain regexps

On 06/17/11 01:46, Jim Meyering wrote: > + MALLOC(merged.elems, position, 2 * d->nleaves); Hmm, aren't other buffer overruns possible in that area, via integer overflows? How about the additional patch given at the end of this message? I haven't tested it because savannah grep doesn't build out

[patch #5316] cannot search for a file if output is redirected to that file

Follow-up Comment #2, patch #5316 (project grep): Many parts of coreutils assume st_dev/st_ino are reliable, e.g., SAME_INODE. With multiple mounts (e.g., NFS) it's possible for the same file to have different st_dev values. GNU tar, on occasion, also looks at st_birthtime, which is a win on sys

Re: Odd grep bug

That is indeed an odd bug, and I can't reproduce it on my RHEL 5.6 (x86-64) host. Here's a transcript of what I did to try to reproduce it: $ export LC_ALL=C $ mkdir d $ echo TRDXST >d/f $ grep -ra2 TRDXST * | grep -v svn d/f:TRDXST If you can come up with a self-contained recipe to reproduce th

Re: [PATCH 08/34] maint: dfa: convert #if-MBS_SUPPORT (dfaoptimize, dfacomp)

After that patch, if I'm reading things correctly, dfaoptimize's body is of the form "if (MBS_SUPPORT) { ... }" and the only call to dfaoptimize is of the form "if (MBS_SUPPORT) dfaoptimize(d);". One of the "if" tests can be removed. I'd remove the one inside "dfaoptimize" as that results in less

Re: [PATCH 1/5] maint: ensure that MB_CUR_MAX is defined even when !MBS_SUPPORT

On 10/10/11 01:03, Paolo Bonzini wrote: > The reason is that then MB_CUR_MAX would be inconsistent with the > behavior of mbrlen and similar functions. Surely it's OK if MB_CUR_MAX is larger than it strictly needs to be. I can't think of any application that would break if MB_CUR_MAX were set to

Re: [PATCH 1/5] maint: ensure that MB_CUR_MAX is defined even when !MBS_SUPPORT

On 10/10/11 08:26, Paolo Bonzini wrote: > Exactly my point, mbrlen could return a value > 1, while MB_CUR_MAX could > have been #undef'ed and redefined to 1. Ah, sorry, I guess I misunderstand the issue. Why don't we use "#define MB_CUR_MAX MB_LEN_MAX" as a fallback then, instead of "#define MB_

Re: grep-2.9.69-f91c on Linux/SPARC

On 11/11/2011 01:37 PM, Jim Meyering wrote: > +/* Do not test things that are likely to change in a growing file. */ \ > +/* && (s)->st_size == (t)->st_size */ \ > +/* && (s)->st_mtime == (t)->st_mtime */ \ > && (s)->st_ctime == (t)->st_ctime) st_ctime is also likely to change in

Re: failure in building gnulib tests wih pcc on debian

On 11/14/11 06:17, Eric Blake wrote: > Is there any easy way to identify pcc at compile time, such as a > preprocessor macro it sets differently than gcc? It's not *easy*, but the C macro __VERSION__ expands to a string that starts with "pcc ". On my host (Fedora 15 x86-64) the exact string is "pc

Re: .tar.xz only policy

On 11/18/11 12:48, Jim Meyering wrote: > For now, I suggest you download the tarball to some other system > and uncompress it before copying it to your ancient vax. I expect he's running OpenBSD/vax under SIMH, rather than on honest-to-goodness VAX hardware. (I used to have a PDP 11/70 in my gara

Re: .tar.xz only policy

On 11/19/11 07:47, Christian Weisgerber wrote: > xz requires a C99 compiler because it intermingles declarations and > statements throughout. So does grep, so I don't see how this is an additional obstacle against building grep. As far as OpenBSD/vax goes, perhaps if you have enough energy you co

Re: any interest in Rational Range Interpretation?

On 11/28/11 09:36, Aharon Robbins wrote: > Hi. Back in the spring we discussed providing Rational Range Interpretation > in GNU tools. I took the plunge with gawk 4.0. > > I can provide diffs for grep without much trouble. > > Is there still interest in this? If so, do I need to update the doc

Re: any interest in Rational Range Interpretation?

On 12/06/11 12:25, Aharon Robbins wrote: > The silence in reaction was deafening. Actually, the silence is encouraging; it means nobody is objecting to it even though they've had a week or so to think about it. Hmm, we'll need papers from you though, since it's nontrivial, right? I don't think

Re: any interest in Rational Range Interpretation?

On 12/10/11 09:07, Paolo Bonzini wrote: > the patches are okay with me, but they will only have an effect as long as > distributors use --with-included-regex In that case, they should be combined with --with-included-regex, or with a test that checks that regular expression handling is rational i

Re: grep-dir test

On 12/19/11 09:21, Eli Zaretskii wrote: > why does it use an empty directory and not an empty file? Because it's testing that grep does the right thing when asked to grep a directory. It doesn't matter that the directory is empty; all that matters is that it's a directory. > The problem with "-f

[bug #34020] RFE: Improve handling of sparse files

Follow-up Comment #2, bug #34020 (project grep): How about the following idea instead (it is simpler and should be more efficient too): Change 'grep' so that by default it ignores all NULs in binary input files. POSIX allows this behavior, and it is typically far more useful than what grep does

[PATCH 1/2] --include etc. now work on command-line args more consistently

--include and --exclude apply only to non-directories and --exclude-dir applies only to directories. "-" (standard input) is never excluded, since it is not a file name. This bug was discovered while fixing a read-directory bug (Bug#10355). * NEWS: Document this. * src/main.c (main): Implement thi

[PATCH 2/2] don't ignore errors when reading a directory

grep no longer silently suppresses errors when reading a directory as if it were a text file. For example, "grep x ." now reports a read error on most systems; formerly, it ignored the error. Problem reported as an aside by Bob Proulx (Bug#10355). * NEWS: Document this. * src/main.c (grep, grepfil

Re: [PATCH 1/2] --include etc. now work on command-line args more consistently

I didn't know it when I wrote that patch, but it turns out that my patch should fix bug#30792 on Savannah.

[bug #30792] --ignore-dir should not override files passed on the command line

Follow-up Comment #2, bug #30792 (project grep): It's definitely a bug. I discovered the bug independently and submitted a patch to bug-grep@gnu.org just now -- I was about to file a bug report and discovered your bug. The patch is in

[bug #35169] grep should report EISDIR read errors

URL: Summary: grep should report EISDIR read errors Project: grep Submitted by: eggert Submitted on: Sat 24 Dec 2011 02:40:25 AM PST Category: None Severity: 3 - Normal

Re: MS-Windows build of Grep [2/4]

I agree with Jim that patch 1/4 is no longer needed. Also, the first hunk of patch 3/4 should be removed as that also has already been fixed, in a different way. Some thoughts on patch 2/4: > +static int is_tty; It'd be nicer if we didn't have to introduce this static variable on POSIX hosts, so

Re: MS-Windows build of Grep [2/4]

removed too, or rewritten from scratch, or something? >From 1bc20aada5bbd57e5edea7bb766d17437726ec82 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 28 Dec 2011 11:31:21 -0800 Subject: [PATCH] ms: move Microsoft-specific stuf to lib/ms * src/main.c (hstdout, norm_attr, w32_console

Re: MS-Windows build of Grep [2/4]

On 12/28/11 12:47, Eli Zaretskii wrote: > Yes, but why under lib/ ? This has nothing to do with any "library". > Why not a subdirectory or src/ ? That'd be fine too. Perhaps eventually they should be libraryized, but you're right that the current code isn't really a library. > I see no machine

Re: MS-Windows build of Grep [2/4]

hanged in gnulib and elsewhere, no doubt. >From a32384b0d025a9d86787622686849599ec3416ca Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 29 Dec 2011 11:08:29 -0800 Subject: [PATCH] ms: move Microsoft-specific stuff to src/ms * configure.ac (GREP_SRC_INCLUDES): New macro. * src/Makefile.am (DEFAULT_INC

Re: MS-Windows build of Grep [2/4]

On 12/29/11 13:56, Paolo Bonzini wrote: > there is no reason to split files Yes there is: separation of concerns. The Microsoft stuff is a separate porting layer, like gnulib, and like gnulib it shouldn't be in the same source directory as the main code. For example, I commonly use 'grep' to scan

Re: MS-Windows build of Grep [2/4]

4c112598a1981787fecfad12890f6540b991f991 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 30 Dec 2011 11:53:40 -0800 Subject: [PATCH] ms: move Microsoft-specific stuff to lib/ms * lib/colorize.c, lib/colorize.h, lib/colorize-impl.c: * lib/ms/colorize.h, lib/ms/colorize-impl.c: New files.

Re: MS-Windows build of Grep [2/4]

On 12/30/11 12:54, Jim Meyering wrote: > You may want to simply exempt those two files from that check. Yes, something like this should do the trick I expect (it includes your later suggestion). I'll wait a bit for more comments, then I intend to push all this, and as a later patch Paolo's sugges

Re: MS-Windows build of Grep [2/4]

On 12/30/11 07:43, Jim Meyering wrote: > Without useful stat.st_ino, there are some important tasks (e.g., dir > traversal) that simply cannot be performed safely/reliably. In general that's true, and on further thought I agree we should leave that part of grep's st_ino code alone. I proposed that

same-inode.h and OpenVMS

On OpenVMS st_ino is an array of three ino_t values, so grep's a.st_ino == b.st_ino compares *pointers*, and yields 0. Ouch. For other GNU programs we often don't worry about OpenVMS, but grep is a special case, as it's actually used on OpenVMS and

Re: MS-Windows build of Grep [2/4]

On 12/30/11 07:43, Jim Meyering wrote: > Without useful stat.st_ino, there are some important tasks (e.g., dir > traversal) that simply cannot be performed safely/reliably. True, but a stricter approach for st_ino, while good for coreutils, may not be as good a match for grep. grep's philosophy

Re: same-inode.h and OpenVMS

OK, thanks, I installed the gnulib patch. I also installed the following gnulib documentation change to try to get all this stuff written down better. doc: cover st_ino issues once; add OpenVMS etc. * doc/posix-functions/stat.texi (stat): * doc/posix-functions/lstat.texi (lstat): * doc/posix-func

Re: same-inode.h and OpenVMS

On 12/31/11 01:20, Jim Meyering wrote: > Obviously an improvement, and no semantic change, > assuming the existing SAME_INODE macro. OK, I pushed that into the grep trunk.

Re: MS-Windows build of Grep [2/4]

On 12/30/11 12:45, Paolo Bonzini wrote: > Looks pretty good, can you just (as a followup) turn the uppercase-named > functions to lowercase? Sure; I installed the Microsoft-moving patch (with a couple of minor bugs fixed, includes in the wrong place): http://git.savannah.gnu.org/cgit/grep.git/c

[PATCH] grep: prefer fgets to printf, _ to gettext

Here's a proposed minor cleanup patch. * lib/colorize.h (print_end_colorize): * lib/ms/colorize-impl.c (print_end_colorize): Use fputs instead of printf. * src/main.c (usage): Likewise. Use _ instead of gettext. --- lib/colorize.h |2 +- lib/ms/colorize-impl.c |2 +- src/main.c

[PATCH] grep: check stdin like other files

I found this bug while thinking about improving the performance of 'grep' on binary files. = * src/main.c (grepfile): Revamp tests for input files so that standard input is tested like other files. For example, report an error if standard input equals standard output. Prefer open+fstat to st

Re: [PATCH] grep: check stdin like other files

On 01/01/12 05:50, Jim Meyering wrote: > IMHO, "_result" is an unnecessarily generic name, and decl-after-stmt > is ok for grep proper (but not dfa.c), so how about this instead? > > bool stat_fail = (desc < 0 >? stat (file, &stats->stat) >: fs

[PATCH] grep: -r with no args now searches "."

This is a patch I've been meaning to write for years. Currently, one must write "grep -r PAT ." to search the working directory recursively, and that trailing " ." is an annoyance. When I added support for "grep -r", I forgot to have "grep -r PAT" search the working directory by default, instead of

Re: [PATCH 3/9] dfa: use MALLOC/REALLOC always

On 01/03/12 00:38, Paolo Bonzini wrote: > - cpp = xnrealloc(cpp, i + 2, sizeof *cpp); > + REALLOC(cpp, i + 2); Missing space before '('; otherwise it looks fine.

Re: empty pattern: info clarification?

m better: >From cb0745b1fec8f050567ab6a2dc5b68d2c55827a2 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 3 Jan 2012 10:09:51 -0800 Subject: [PATCH] doc: document empty pattern better * doc/grep.texi (Top, Fundamental Structure, Usage): Explain how grep deals with the empty pattern. Prob

Re: [PATCH 3/3] remove lib/ms/

The point of lib/ms was so that if I do this: cd lib grep something *.[ch] I don't find false matches for the Microsoft-specific stuff. Now that lib/ms/* has been moved into lib/*, I can't do that any more. I'd really like for the Microsoft-specific code to be segregated better, so that I don't

Re: [PATCH] grep: -r with no args now searches "."

documentation / help a bit more. Anyway, rather than revert, how about the following patch? >From 56b252075f85edfdaf6123fdd147a8c0682d1e50 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 3 Jan 2012 14:42:28 -0800 Subject: [PATCH] grep: with no args, search "." only if comma

Re: [PATCH] grep: -r with no args now searches "."

On 01/04/12 01:51, Paolo Bonzini wrote: > the difference here is that GREP_OPTIONS=-r, > no matter how debatable it is, is not an unintentional mistake Yes, but this is completely addressed by the proposed patch in , no? > I must

Re: empty pattern: info clarification?

On 01/04/12 01:24, Voelker, Bernhard wrote: > Thanks, I like it. OK, thanks, I pushed what I hope is an even slightly better version that talks about matching empty and blank lines. It's like what I emailed previously, except the last paragraph now looks like this: To match empty lines, use the p

Re: proposed patch to dfa.c

valid unibyte character"; it really means "it won't mess up the word-constituent test if you pass C to isalnum". Maybe we should rename it at some point... >From 1e83f7f353219be88339032d9e21dbef1f64108e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 12 Jan 2012

Re: Rational Range Interpretation patches, 1/3

On 01/16/12 12:24, Aharon Robbins wrote: > +#include Why was this change needed? None of the other bits of inserted code use bool.

Re: Rational Range Interpretation patches, 2/3

On 01/16/12 12:25, Aharon Robbins wrote: > -These variables specify the locale for the @code{LC_COLLATE} category, > -which determines the collating sequence > -used to interpret range expressions like @samp{[a-z]}. > +These variables specify the locale for the @code{LC_COLLATE} category. The revi

Re: Rational Range Interpretation patches, 2/3

On 01/16/12 23:42, arn...@skeeve.com wrote: >> I assume LC_COLLATE still affects equivalence >> > classes, such as those in '[[=a=]b]', and that it still >> > affects collating symbols, such as the 'ch' in '[[.ch.]]' > The truth is, I have no idea what it's used for, so I didn't > say anything. Ca

Re: [PATCH] main.c: exit on the first EPIPE error

How about this simpler patch instead? It simply bails on write error, which ought to be good enough in practice. Come to think of it, most of the other "error (0, ...)"s are bogus -- I'll try to take a look at them and post a more-systematic patch along the following lines.

Re: [PATCH 0/8] fix problems with ^ and $ together with \< and \>

Thanks for fixing that bug! I didn't had time to review every bit of the change but what I did look at looked good.

[PATCH 1/4] grep: don't say "write error" over and over

On 01/20/2012 09:52 AM, Paul Eggert wrote: > Come to think of it, most of the other "error (0, ...)"s are bogus I took a look and came up with four related patches to fix these. Here's the first one. It fixes the originally-reported bug. I'll send the othe

[PATCH 2/4] grep: suppress read errors if -s

* src/main.c (reset, grep, grepfile): Do not report an input error if -s is given. --- src/main.c | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/src/main.c b/src/main.c index 62ce7e3..893f025 100644 --- a/src/main.c +++ b/src/main.c @@ -502,7 +502,7 @@ reset (in

[PATCH 3/4] grep: exit with nonzero status if directory loop

* src/main.c (grepdir): Exit with status 2 if a directory loop is found, since the output might not be "right" (i.e., infinite...). --- src/main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/main.c b/src/main.c index 893f025..84564e0 100644 --- a/src/main.c +++ b/s

[PATCH 4/4] grep: be quiet about GREP_COLORS syntax

* src/main.c (struct color_cap): fct now returns void, since there's no longer need to use what it returns. (color_cap_mt_fct, color_cap_rv_fct, color_cap_ne_fct): Return void. (parse_grep_colors): Do not output diagnostics and then exit with status 0. Instead, ignore errors in GREP_COLORS. This

Re: [PATCH 4/4] grep: be quiet about GREP_COLORS syntax

On 01/20/2012 11:46 PM, Paolo Bonzini wrote: > All patches look good! Can you write a NEWS entry and push? Sure, I pushed this NEWS change along with the rest. Thanks for reviewing. doc: document recent diagnostics-related changes * NEWS: Document changes re diagnostics related to GREP_COLORS, d

[PATCH] maint: quote 'like this' or "like this", not `like this'

. (state_index): initialize mbps in multibyte environments. (epsclosure): handle ANYCHAR. @@ -2166,7 +2166,7 @@ 2000-03-03 Jim Meyering -* regex.m4: Make sure re_compile_pattern accepts patterns like `{1'. +* regex.m4: Make sure re_compile_pattern accept

Re: releasing grep-2.11 soon

On 01/30/2012 08:00 AM, Jim Meyering wrote: > Is there anything else people think should be considered? I'd also like to put in the quoting-style changes of . Some quoting-style changes were put in about a week ago, and it'd be nice

Re: Building grep 2.9 on SunOS 4

On 02/03/2012 02:38 PM, Michael Haardt wrote: > I am afraid that being active maintainer asks for more time than I have That's quite understandable. I used SunOS 4 heavily, but it's now just a museum piece, and it doesn't appear to be worth your time or ours to maintain GNU utilities on it. (If t

Re: [PATCH 1/4] grep: don't say "write error" over and over

On 01/20/2012 11:06 PM, Paul Eggert wrote: > I took a look and came up with four related patches to fix these. > Here's the first one. It fixes the originally-reported bug. I found a problem in that patch's test case: it assumes that SIGPIPE has the default action when the te

Re: [PATCH 1/4] grep: don't say "write error" over and over

Thanks for reviewing that. What a mess! An odd thing is that the patch *did* fix things for Fedora 15. Maybe its shell is busted? But that's a different matter. I think we can address this particular problem without relying on a new coreutils feature, though the feature you mention does sound u

Re: Sporadic superfluous successful exits

On 02/09/2012 01:35 AM, Aki Helin wrote: > A date just got printed without issues even though > it was matching with Grep that had been patched to crash if it tries to > exit with 0 from the bottom of main(). Sounds like the bug's outside of 'grep', then. I'm not observing any problems with simil

[bug #35518] Correct gettext/iconv linking

Follow-up Comment #1, bug #35518 (project grep): I don't see why the patch is needed, or how the patch can work in general. Grep doesn't use libtool, and surely LTLIBINTL and LTLIBICONV aren't reliable in the absence of libtool. ___ Reply t

Re: [PATCH 1/4] grep: don't say "write error" over and over

Thanks for reporting that; I pushed this slightly different patch: * tests/epipe: Don't loop forever if the bug is present. Problem reported by Jaroslav Skarvada. --- tests/epipe | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/tests/epipe b/tests/epipe index 1d

Re: avoid gcc 4.6.2 'may be used before set' warnings in dfa.c

On 02/15/2012 10:54 AM, Aharon Robbins wrote: > - int c, c1, c2; > + int c = 0, c1 = 0, c2 = 0; Sorry, I don't see why this patch (and the other) is needed. grep's copy of src/dfa.h says this: extern void dfaerror (const char *) __attribute__ ((noreturn)); and all paths to the first use of c o

Re: avoid gcc 4.6.2 'may be used before set' warnings in dfa.c

ou like. >From fdfa5e9132ca3c57814d752349f4a9a7eeacf573 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 24 Feb 2012 17:25:50 -0800 Subject: [PATCH] maint: use stdnoreturn.h rather than rolling our own * bootstrap.conf (gnulib_modules): Add stdnoreturn. * src/grep.h (__attribute__): Remove. * src/df

Re: avoid gcc 4.6.2 'may be used before set' warnings in dfa.c

#endif ]) Here's a patch to 'grep' that would implement this idea. I don't have a strong feeling about this versus the patch; either would be OK with me. >From 09ee44ff05019961930c

[bug #35169] grep should report EISDIR read errors

Update of bug #35169 (project grep): Open/Closed:Open => Closed ___ Follow-up Comment #1: This was fixed in the trunk in December 2011, in commit d0be2a62a38726211cd94a06fd7e9aa23a88d07d.

[bug #34917] grep refuses to run when input file is also the output, even when the -q option is used

Update of bug #34917 (project grep): Open/Closed:Open => Closed ___ Follow-up Comment #2: This bug was fixed in the master in December 2011 with commit ed071726be5758b1422d7972450a186765526

[bug #35518] Correct gettext/iconv linking

Update of bug #35518 (project grep): Status:None => Need Info ___ Follow-up Comment #2: No response for a while, so I'm marking this bug "Need Info".

[bug #34930] grep 2.10 fails to build (no wide char support OS)

Update of bug #34930 (project grep): Open/Closed:Open => Closed ___ Follow-up Comment #2: This bug was fixed in the grep master in December 2011, in commit 0ba89c07c583fb7bc24225f6dca66fd06

[bug #33965] --include broken (AGAIN)

Update of bug #33965 (project grep): Status:None => Need Info Open/Closed:Open => Closed ___ Follow-up Comment #2: I can't reproduce the

[bug #33868] configure fails on HP-UX

Update of bug #33868 (project grep): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks, this bug was fixed in gnulib in June 2011, as commit 0f247f994ecf88c40563c2d264536a1aa7634b

[bug #33747] Use rm -f in gnulib-tests

Update of bug #33747 (project grep): Status:None => Need Info ___ Follow-up Comment #1: I dunno, there are lots of other places in the grep source code that use 'rm' without '-f'. Is it

[bug #33710] make check fails on test-float test on PPC

Update of bug #33710 (project grep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #3: Since we've upgraded g

[bug #35169] grep should report EISDIR read errors

Update of bug #35169 (project grep): Status:None => Fixed ___ Reply to this item at: ___ Messag

[bug #34917] grep refuses to run when input file is also the output, even when the -q option is used

Update of bug #34917 (project grep): Status:None => Fixed ___ Reply to this item at: ___ Messag

[bug #34930] grep 2.10 fails to build (no wide char support OS)

Update of bug #34930 (project grep): Status:None => Fixed ___ Reply to this item at: ___ Messag

[bug #33868] configure fails on HP-UX

Update of bug #33868 (project grep): Status:None => Fixed ___ Reply to this item at: ___ Messag

[PATCH 1/5] tests: test for problems with long matches

The new test is expensive, so add a category of expensive tests, which are normally not run, and put the new test in this new category. The idea of having expensive tests is taken from coreutils. * HACKING: Mention RUN_EXPENSIVE_TESTS and similar env vars. * Makefile.am (check-expensive): New rule

[PATCH 2/5] grep: fix some core dumps with long lines etc.

These problems mostly occur because the code attempts to stuff sizes into int or into unsigned int; this doesn't work on most 64-bit hosts and the errors can lead to core dumps. * NEWS: Document this. * src/dfa.c (token): Typedef to ptrdiff_t, since the enum's range could be as small as -128 .. 127

[PATCH 3/5] grep: remove no-longer-used setrlimit code

This code has been unused and obsolescent ever since the regex code stopped using the stack for large regular expressions. * src/main.c [HAVE_SETRLIMIT]: Do not include or or ; no longer needed. (set_rlimits): Remove. All callers changed. --- src/main.c | 38 ---

[PATCH 4/5] grep: avoid mishandling of long lines

* src/pcresearch.c (Pexecute): Do not pass a line longer than INT_MAX to pcre_exec, since its API does not permit that. --- src/pcresearch.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/pcresearch.c b/src/pcresearch.c index 2eda5f1..2994e65 100644 --- a/src/pcrese

[PATCH 5/5] grep: fix integer-overflow issues in main program

* NEWS: Document this. * bootstrap.conf (gnulib_modules): Add inttypes, xstrtoimax. Remove xstrtoumax. * src/main.c: Include , for INTMAX_MAX, PRIdMAX. (context_length_arg, prtext, grepbuf, grep, grepfile) (get_nondigit_option, main): Use intmax_t, not int, for line counts. (context_length_arg, mai

  1   2   3   4   5   6   7   8   9   10   >