threads / discuss / 42063

Binary grep t7008 known breakage vanished on Cygwin

Subject: Binary grep t7008 known breakage vanished on Cygwin

## tl;dr

4 messages between Apr 18, 2016 and Apr 19, 2016.

replies: 3people: 2as markdown or json

Adam Dinwoodie· Apr 18, 2016, 15:21 UTC · lore

t7008.12 is marked as an expected failure, but building Git on Cygwin including a `make configure && ./configure` step has the test unexpectedly passing. Building without the configure step has the test failing as expected.

This appears to be behaviour specific to Cygwin; at least I get that test failing on my CentOS box regardless of whether I perform the configure step.

The "problem" here is `git grep` is matching a null byte with a "."; the test implies that ought to work in theory but hasn't worked in practice since the test was added in v1.7.1-101-gf96e567. The commit message there asserts "NUL characters themselves are not matched in any way, though", which is evidently not the case on Cygwin, provided the `configure` script is run.

I'm not sufficiently familiar with the standards and library interfaces here to have any idea what the "correct" regex behaviour in this circumstance is.

I'm not sure what the correct thing to do in the face of such an unexpected test pass; it looks as though Cygwin Git's `grep` is going to behave in a subtly different way to Git on other platforms as a result of this, which is probably not ideal, but I don't know if there's anything that "ought" to be done to either ensure consistent behaviour across platforms, or to stop marking the test as an expected failure on platforms where it passes.

Adam

Ramsay Jones· Apr 18, 2016, 17:08 UTC · re: Adam Dinwoodie · lore

Re: Binary grep t7008 known breakage vanished on Cygwin

On 18/04/16 16:21, Adam Dinwoodie wrote:

Show 8 quoted lines

> t7008.12 is marked as an expected failure, but building Git on Cygwin
> including a `make configure && ./configure` step has the test
> unexpectedly passing.  Building without the configure step has the test
> failing as expected.
> 
> This appears to be behaviour specific to Cygwin; at least I get that
> test failing on my CentOS box regardless of whether I perform the
> configure step.

Yes, the configure sets NO_REGEX= whereas the config.mak.uname sets NO_REGEX=UnfortunatelyYes.

[Note that the regex bug (see t0070-fundamental.sh test #5) now seems to pass with the 'native' regex library]

ATB, Ramsay Jones

Adam Dinwoodie· Apr 19, 2016, 08:42 UTC · re: Ramsay Jones · lore

Re: Binary grep t7008 known breakage vanished on Cygwin

On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote:

Show 15 quoted lines

> On 18/04/16 16:21, Adam Dinwoodie wrote:
> > t7008.12 is marked as an expected failure, but building Git on Cygwin
> > including a `make configure && ./configure` step has the test
> > unexpectedly passing.  Building without the configure step has the test
> > failing as expected.
> > 
> > This appears to be behaviour specific to Cygwin; at least I get that
> > test failing on my CentOS box regardless of whether I perform the
> > configure step.
> 
> Yes, the configure sets NO_REGEX= whereas the config.mak.uname sets
> NO_REGEX=UnfortunatelyYes.
> 
> [Note that the regex bug (see t0070-fundamental.sh test #5) now seems to
> pass with the 'native' regex library]

Ah, that makes sense.

I'm still not quite sure what the "correct" thing to do here is; it looks as though the NOREGEX=UnfortunatelyYes can disappear from config.mak.uname, but that still leaves t7008.12 passing when it's expected to fail.

Adam

Ramsay Jones· Apr 19, 2016, 18:52 UTC · re: Adam Dinwoodie · lore

Re: Binary grep t7008 known breakage vanished on Cygwin

On 19/04/16 09:42, Adam Dinwoodie wrote:

Show 23 quoted lines

> On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote:
>> On 18/04/16 16:21, Adam Dinwoodie wrote:
>>> t7008.12 is marked as an expected failure, but building Git on Cygwin
>>> including a `make configure && ./configure` step has the test
>>> unexpectedly passing.  Building without the configure step has the test
>>> failing as expected.
>>>
>>> This appears to be behaviour specific to Cygwin; at least I get that
>>> test failing on my CentOS box regardless of whether I perform the
>>> configure step.
>>
>> Yes, the configure sets NO_REGEX= whereas the config.mak.uname sets
>> NO_REGEX=UnfortunatelyYes.
>>
>> [Note that the regex bug (see t0070-fundamental.sh test #5) now seems to
>> pass with the 'native' regex library]
> 
> Ah, that makes sense.
> 
> I'm still not quite sure what the "correct" thing to do here is; it
> looks as though the NOREGEX=UnfortunatelyYes can disappear from
> config.mak.uname, but that still leaves t7008.12 passing when it's
> expected to fail.

Yep. ;-)

About two years ago, I went from 32-bit 1.5 to 32-bit 1.7 then 64-bit 1.7. At that time the 'native' regex library suffered from the 'regex bug' (ie it failed t0070.5). It also 'unexpectedly passed' t7008.12. However, since the fix for t0070.5 was to use the compat/regex library, I didn't have to give t7008.12 any thought. :-D

I am currently running:

    $ uname -a
    CYGWIN_NT-10.0 satellite 2.4.0(0.293/5/3) 2016-01-15 16:16 x86_64 Cygwin
    $

Until yesterday, I didn't know that the native regex library no longer suffers from the t0070.5 bug. I simply don't use the configure script - never have. It seems that t7008.12 is still an issue, however.

The commit which added that test, commit f96e5673, seems to expect that NUL characters should not be matched in any way. Now, _if_ you accept that this is correct behaviour, then the native regex library on Cygwin still has a problem.

Maybe we need to add a check to test-regex (and/or configure)? dunno. Alternatively, we could skip the test with a !CYGWIN prerequisite.

[Again, I don't use configure or the native regex library]

ATB, Ramsay Jones