GNU bug report logs - #39678
'grep --ignore-case --color' does not always color the matches

Previous Next

Full log

Message #44 received at 39678 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Tomasz Dziendzielski <tomasz.dziendzielski <at> gmail.com>
Cc: 39678 <at> debbugs.gnu.org
Subject: Re: bug#39678: 'grep --ignore-case --color' does not always color the
 matches
Date: Mon, 18 Oct 2021 09:59:19 -0700

On 10/17/21 21:53, Tomasz Dziendzielski wrote:
> Thanks for the reply. In my opinion the bug is not in the EGexecute, since
> it uses re_search (from gnulib) and the re_search is not returning a match.
> So there is no problem in EGexecute.

It seems to me that there is a bug, because the search in question is 
done to a line for which EGexecute has already reported a match. 
Therefore, if you search again with the same pattern, you should find at 
least one match. However, in this buggy case, EGexecute is not finding a 
match, and this messes up the caller.

> even if we assume it should return a match (which I think it
> shouldn't), then there's a second bug in print_line_middle, because why
> would it print anything if there was no match?

It should be able to assume that there is at least one match, so it 
shouldn't need to worry about the case where there are zero matches.

> which means that escaping ordinary characters (like \a) has undefined
> behaviour,

Yes, and that means this bug is not a POSIX-conformance issue. However, 
it's still a bug, since '\a' should match 'a' in GNU grep, at least 
unless and until we decide that \a matches something else.

> So having EGexecute match 'a' to '\a' is incorrect

Not at all. Undefined behavior means 'grep' can do anything it likes, as 
far as POSIX is concerned.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.