From: Karthik Nayak <karthik.188@gmail.com>
Date: Sat, 31 May 2025 21:28:47 GMT
Subject: Re: [PATCH v3 07/10] t7815: fix unexpectedly passing test on macOS
Message-ID: <CAOLa=ZRp=-x3eDXvb1WMCwT4FXU+YbiJYTfo3=kiGfO5GHSR5Q@mail.gmail.com>
In-Reply-To: <20250530-pks-meson-tap-v3-7-676f5e41f2e4@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

> In t7815, we have the following test:
>
>     test_expect_failure !CYGWIN 'git grep .fi a' '
>         git grep .fi a
>     '
>
> The test passes if '.' matches a NUL byte, which we expect to only
> happen on Cygwin. The upcoming changes to support parsing TAP output in
> Meson surface that this test is also unexpectedly passing on macOS
> though.
>
> It is unclear how long the test has been passing on macOS already.
> 064eed36c7f (config.mak.uname: only set NO_REGEX on cygwin for v1.7,
> 2025-04-17) mentions that the test started to pass for Cygwin once it
> has imported a newer implementation of regcomp(3p) et all, which was
> inherited from FreeBSD. Given the BSD lineage of macOS it is feasible
> that it also inherited similar code eventually that made the test pass
> now.
>
> It is somewhat dubious what the test actually brings to the table given
> that it is quite platform specific. Ideally, we would fix this mess by
> having a configure-time check whether regcomp(3p) works as expected,
> including NUL bytes, and use our bundled version of the regex library in
> case it doesn't. Like this, we could ensure that all platforms work the
> same in this edge case and mark the new behaviour as expected.
>
> This change is outside of the scope of this patch series, which only
> introduce support for TAP. So instead of fixing the bigger issue, ignore

Nit: s/introduce/introduces

> the test on Darwin like we already do for Cygwin.
>

The change makes sense to me.

[snip]