{"thread":{"id":"42063","subject":"Binary grep t7008 known breakage vanished on Cygwin","startedAt":"2016-04-18T15:21:49Z","lastAt":"2016-04-19T18:52:11Z","messageCount":4,"participants":["Adam Dinwoodie","Ramsay Jones"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"283730","messageId":"20160418152149.GD2345@dinwoodie.org","threadId":"42063","inReplyTo":null,"subject":"Binary grep t7008 known breakage vanished on Cygwin","fromName":"Adam Dinwoodie","fromEmail":"adam@dinwoodie.org","sentAt":"2016-04-18T15:21:49Z","receivedAt":"2016-04-18T15:21:49Z","isPatch":false,"sender":{"key":"adam@dinwoodie.org","avatar":"https://avatars.githubusercontent.com/u/1397507?v=4"},"body":"t7008.12 is marked as an expected failure, but building Git on Cygwin\nincluding a `make configure && ./configure` step has the test\nunexpectedly passing.  Building without the configure step has the test\nfailing as expected.\n\nThis appears to be behaviour specific to Cygwin; at least I get that\ntest failing on my CentOS box regardless of whether I perform the\nconfigure step.\n\nThe \"problem\" here is `git grep` is matching a null byte with a \".\"; the\ntest implies that ought to work in theory but hasn't worked in practice\nsince the test was added in v1.7.1-101-gf96e567.  The commit message\nthere asserts \"NUL characters themselves are not matched in any way,\nthough\", which is evidently not the case on Cygwin, provided the\n`configure` script is run.\n\nI'm not sufficiently familiar with the standards and library interfaces\nhere to have any idea what the \"correct\" regex behaviour in this\ncircumstance is.\n\nI'm not sure what the correct thing to do in the face of such an\nunexpected test pass; it looks as though Cygwin Git's `grep` is going to\nbehave in a subtly different way to Git on other platforms as a result\nof this, which is probably not ideal, but I don't know if there's\nanything that \"ought\" to be done to either ensure consistent behaviour\nacross platforms, or to stop marking the test as an expected failure on\nplatforms where it passes.\n\nAdam\n"},{"id":"283734","messageId":"5715147F.7020609@ramsayjones.plus.com","threadId":"42063","inReplyTo":"20160418152149.GD2345@dinwoodie.org","subject":"Re: Binary grep t7008 known breakage vanished on Cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-04-18T17:08:15Z","receivedAt":"2016-04-18T17:08:15Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 18/04/16 16:21, Adam Dinwoodie wrote:\n> t7008.12 is marked as an expected failure, but building Git on Cygwin\n> including a `make configure && ./configure` step has the test\n> unexpectedly passing.  Building without the configure step has the test\n> failing as expected.\n> \n> This appears to be behaviour specific to Cygwin; at least I get that\n> test failing on my CentOS box regardless of whether I perform the\n> configure step.\n\nYes, the configure sets NO_REGEX= whereas the config.mak.uname sets\nNO_REGEX=UnfortunatelyYes.\n\n[Note that the regex bug (see t0070-fundamental.sh test #5) now seems to\npass with the 'native' regex library]\n\nATB,\nRamsay Jones\n"},{"id":"283775","messageId":"20160419084232.GE2345@dinwoodie.org","threadId":"42063","inReplyTo":"5715147F.7020609@ramsayjones.plus.com","subject":"Re: Binary grep t7008 known breakage vanished on Cygwin","fromName":"Adam Dinwoodie","fromEmail":"adam@dinwoodie.org","sentAt":"2016-04-19T08:42:32Z","receivedAt":"2016-04-19T08:42:32Z","isPatch":false,"sender":{"key":"adam@dinwoodie.org","avatar":"https://avatars.githubusercontent.com/u/1397507?v=4"},"body":"On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote:\n> On 18/04/16 16:21, Adam Dinwoodie wrote:\n> > t7008.12 is marked as an expected failure, but building Git on Cygwin\n> > including a `make configure && ./configure` step has the test\n> > unexpectedly passing.  Building without the configure step has the test\n> > failing as expected.\n> > \n> > This appears to be behaviour specific to Cygwin; at least I get that\n> > test failing on my CentOS box regardless of whether I perform the\n> > configure step.\n> \n> Yes, the configure sets NO_REGEX= whereas the config.mak.uname sets\n> NO_REGEX=UnfortunatelyYes.\n> \n> [Note that the regex bug (see t0070-fundamental.sh test #5) now seems to\n> pass with the 'native' regex library]\n\nAh, that makes sense.\n\nI'm still not quite sure what the \"correct\" thing to do here is; it\nlooks as though the NOREGEX=UnfortunatelyYes can disappear from\nconfig.mak.uname, but that still leaves t7008.12 passing when it's\nexpected to fail.\n\nAdam\n"},{"id":"283828","messageId":"57167E5B.6060505@ramsayjones.plus.com","threadId":"42063","inReplyTo":"20160419084232.GE2345@dinwoodie.org","subject":"Re: Binary grep t7008 known breakage vanished on Cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-04-19T18:52:11Z","receivedAt":"2016-04-19T18:52:11Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 19/04/16 09:42, Adam Dinwoodie wrote:\n> On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote:\n>> On 18/04/16 16:21, Adam Dinwoodie wrote:\n>>> t7008.12 is marked as an expected failure, but building Git on Cygwin\n>>> including a `make configure && ./configure` step has the test\n>>> unexpectedly passing.  Building without the configure step has the test\n>>> failing as expected.\n>>>\n>>> This appears to be behaviour specific to Cygwin; at least I get that\n>>> test failing on my CentOS box regardless of whether I perform the\n>>> configure step.\n>>\n>> Yes, the configure sets NO_REGEX= whereas the config.mak.uname sets\n>> NO_REGEX=UnfortunatelyYes.\n>>\n>> [Note that the regex bug (see t0070-fundamental.sh test #5) now seems to\n>> pass with the 'native' regex library]\n> \n> Ah, that makes sense.\n> \n> I'm still not quite sure what the \"correct\" thing to do here is; it\n> looks as though the NOREGEX=UnfortunatelyYes can disappear from\n> config.mak.uname, but that still leaves t7008.12 passing when it's\n> expected to fail.\n\nYep. ;-)\n\nAbout two years ago, I went from 32-bit 1.5 to 32-bit 1.7 then 64-bit 1.7.\nAt that time the 'native' regex library suffered from the 'regex bug' (ie it\nfailed t0070.5). It also 'unexpectedly passed' t7008.12. However, since the\nfix for t0070.5 was to use the compat/regex library, I didn't have to give\nt7008.12 any thought. :-D\n\nI am currently running:\n\n    $ uname -a\n    CYGWIN_NT-10.0 satellite 2.4.0(0.293/5/3) 2016-01-15 16:16 x86_64 Cygwin\n    $ \n\nUntil yesterday, I didn't know that the native regex library no longer suffers\nfrom the t0070.5 bug. I simply don't use the configure script - never have.\nIt seems that t7008.12 is still an issue, however.\n\nThe commit which added that test, commit f96e5673, seems to expect that NUL\ncharacters should not be matched in any way. Now, _if_ you accept that this\nis correct behaviour, then the native regex library on Cygwin still has a\nproblem.\n\nMaybe we need to add a check to test-regex (and/or configure)? dunno.\nAlternatively, we could skip the test with a !CYGWIN prerequisite.\n\n[Again, I don't use configure or the native regex library]\n\nATB,\nRamsay Jones\n"}]}