[Top][All Lists]

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

bug#17246: grep-2.19 planning

From: Paolo Bonzini
Subject: bug#17246: grep-2.19 planning
Date: Mon, 12 May 2014 22:55:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Il 12/05/2014 21:40, Paul Eggert ha scritto:

Now, what does "matcher &&" mean there?  If 'matcher' is null, we are
using grep and no matcher has been specified; as it happens (though
there's no comment to this effect) 'matcher' cannot be null in fgrep
even when a matcher has not been specified.  So "matcher &&" means "(we
are not using the grep matcher) &&".  This code is correct, but it's
confusing, and this caused Norihiro to propose even-more-confusing
patches like this in

  if (match_icase && MB_CUR_MAX > 1 && keycc
      && ((!matcher && STREQ (matchers[0].name, "fgrep"))
          || (matcher && STREQ (matcher, "fgrep"))))

Here the second line is unnecessary -- or perhaps I'm not understanding
things correctly, but then the code is *really* confusing.

Grep maintainers shouldn't have to worry about stuff like this. Instead,
we should separate the concerns of egrep and fgrep, so that they do not
affect the mainstream grep code.

This kind of change can be done independent of the change to shell scripts.


reply via email to

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