emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44351: closed (Bug in grep v3.2 onwards in regular expression matchi


From: GNU bug Tracking System
Subject: bug#44351: closed (Bug in grep v3.2 onwards in regular expression matching)
Date: Sun, 01 Nov 2020 18:04:01 +0000

Your message dated Sun, 1 Nov 2020 10:03:37 -0800
with message-id <8f9e431e-23d5-0445-4d2d-063eb1e8f53a@cs.ucla.edu>
and subject line Re: bug#44351: Bug in grep v3.2 onwards in regular expression 
matching
has caused the debbugs.gnu.org bug report #44351,
regarding Bug in grep v3.2 onwards in regular expression matching
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
44351: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44351
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Bug in grep v3.2 onwards in regular expression matching Date: Sat, 31 Oct 2020 14:14:55 +0100
Hello,

  While using GNU grep v3.4 in an Ubuntu 20.04 userspace running on top of Win10 WSL (yeah, i know... but also checked in other envs) i discovered what seems like an obvious bug (if i'm not mistaken).
  The bug:
-----
me@host:~$  echo 'xxxxy' |grep -E '^x+x+x+x+y$'
xxxxy
me@host:~$  echo 'xxxy' |grep -E '^x+x+x+x+y$'
xxxy
me@host:~$  echo 'xxy' |grep -E '^x+x+x+x+y$'
xxy
me@host:~$  echo 'xy' |grep -E '^x+x+x+x+y$'

----
...the terminal supports ansi color escapes, and what's really weird is that only the result from the first command is colored in red. First and fourth commands yield correct results; the second and third do not, as they should not match it's input.

  I've tested releases from v3.1 to latest v3.5 and found the anomalous behaviour in version v3.2 through v3.5. A (quick and clunky) git bisect led me to believe it was introduced about two years ago, possibly in commit 123620af88f55c3e0cc9f0aed7311c72f625bc82 (https://git.savannah.gnu.org/cgit/grep.git/commit/?id=123620af88f55c3e0cc9f0aed7311c72f625bc82). If this is true, it would mean either the bug is in gnulib, or maybe grep needed to do some kind of extra handling on it's side.

Kind regards. Gonzalo Padrino.

P.S.: I had to patch some things in order to successfully compile the code after checking out some problematic commits (pragmas to avoid warnings about "pure" and "noreturn" function attributes, a missing configmake dependency in bootstrap.conf, etc ).

--- End Message ---
--- Begin Message --- Subject: Re: bug#44351: Bug in grep v3.2 onwards in regular expression matching Date: Sun, 1 Nov 2020 10:03:37 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
Thanks to all for the bug report and quick fix. Closing the bug report.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]