Control: tags -1 + patch
El 07/10/14 a las 09:27, Paul Eggert escribió:
> Hmmm, well, to me the proposed clarification is not that clear either. And
> the man page is no place for a chatty discussion about what POSIX allows of
> other implementations; the full manual is the place for that sort of
Jim Meyering wrote:
> I used git bisect to determine precisely where this happened:
>
> git bisect start v2.19 v2.18
> git bisect run sh -c 'make WERROR_CFLAGS= && test $(printf "a\naa\n"
> | LC_ALL=zh_CN src/grep ..|wc -l) = 1'
>
> It found v2.18-123-geb3292b, so I've updated the commit log
Norihiro Tanaka wrote:
> Sorry, I investigated many cases, but I couldn't find it.
>
> When this bug is reproduced, must be s == 0 and s1 > 0 and
> d->newlines[s] != d->newlines[s1]. In addition, they mustn't be
> updated until reaches a next newline.
>
> I believe that all of them is never fil
On Wed, Oct 8, 2014 at 3:41 PM, Norihiro Tanaka wrote:
> Norihiro Tanaka wrote:
>> Sorry, I investigated many cases, but I couldn't find it.
>>
>> When this bug is reproduced, must be s == 0 and s1 > 0 and
>> d->newlines[s] != d->newlines[s1]. In addition, they mustn't be
>> updated until reache
On Mon, Oct 6, 2014 at 8:37 AM, Norihiro Tanaka wrote:
> After search potential match at initial state, a current state may be
> updated. So we must set 0 to previous state.
I too have a hard time seeing how this change can make a difference,
but will go ahead and push the attached change in you
Jim Meyering wrote:
it
is fine that you closed it.
Hah! And I reopened it at his request. Closing it again.
