Re: [PATCH 06/12] config.mak.uname: only set NO_REGEX on cygwin for v1.7

[Junio C Hamano <gitster@pobox.com>]

Ramsay Jones <ramsay@ramsayjones.plus.com> writes:

>> After some time (may a year or two), the platform library had been
>> updated (with an import from FreeBSD, I believe) and now passed the full
>> test-suite. This would be about the time of the v1.7 -> v2.0 transition
>> in 2015. I had a patch ready to send, but just didn't get around to
>> submitting it to the list.

So is it safe for us to just drop the bit that sets NO_REGEX and
require Cygwin that is less than 10 years old?  As long as people
are willing to actively maintain the compatibility wart for older
systems there is no strong reason to do so, but at some point it
would become diminishing returns even for those who have hardware to
develop, build, and test on, when the reason they keep such an old
system becomes only to maintain it instead of actively using it,
and I am wondering if Cygwin 1.7 has past that point.

> I forgot to mention, that one of the reasons that I didn't get around
> to submitting this patch then, was because of a '# TODO known breakage
> vanished' in test t7815-grep-binary.sh:
> ...
> The platform regex library is happy to match a NUL byte with the '.'
> pattern. (presumably this is also true on FreeBSD?).

In this test, the haystack has "binary\0file\0m..." and the needle
to be sought is ".fi".  The system I have at hand uses glibc 2.40
and it refuses to match NUL with '.', it seems.

> I could not decide on the best way to 'fix' this issue. The options
> seemed to be: do nothing (it's not hurting anyone), disable the test
> on cygwin or simply remove the test.

The part "On Cygwin" somewhat puzzled me; aren't folks on various
BSD variants seeing the same symptom?

Do we want to eventually turn it to test_expect_success?  I think
the "fix" depends on this single question, and I am not sure if we
do.

Is the behaviour that '.' matches NUL on some platform and doesn't
on some others hurting anybody?  I dislike a tool that behaves
differently depending on the platform, but not strongly enough in
this case somehow.

On the same system, GNU grep and sed seem to consider that '.'
matches NUL there, i.e.

    $ grep -a '.fi' a | cat -v -T
    binary^@file^@m[*]c^@*M-CM-&^@M-CM-0
    $ sed -n -e '/.fi/p' a | cat -v -T


> [I think I prefer to simply delete the test, since it doesn't seem to
> be testing anything useful, as far as I can see.]
>
> What do you think?
>
> ATB,
> Ramsay Jones