|
From: | Paul Eggert |
Subject: | bug#39678: 'grep --ignore-case --color' does not always color the matches |
Date: | Mon, 18 Oct 2021 09:59:19 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |