[PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Junio C Hamano]

Earlier, 54463d32 (use enhanced basic regular expressions on macOS,
2023-01-08) started to use the REG_ENHANCED option when ERE is not
in use on macOS.  The build seems to have started failing on
macos-14 CI jobs at GitHub, however, as apparently not all the macOS
platforms have this flag defined.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 compat/regcomp_enhanced.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/compat/regcomp_enhanced.c b/compat/regcomp_enhanced.c
index 84193ce53b..51e1358170 100644
--- a/compat/regcomp_enhanced.c
+++ b/compat/regcomp_enhanced.c
@@ -3,7 +3,9 @@
 
 int git_regcomp(regex_t *preg, const char *pattern, int cflags)
 {
+#ifdef REG_ENHANCED
 	if (!(cflags & REG_EXTENDED))
 		cflags |= REG_ENHANCED;
+#endif
 	return regcomp(preg, pattern, cflags);
 }
-- 
2.53.0-816-g44373249a2

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[René Scharfe]

On 3/19/26 11:37 PM, Junio C Hamano wrote:
> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,
> 2023-01-08) started to use the REG_ENHANCED option when ERE is not
> in use on macOS.  The build seems to have started failing on
> macos-14 CI jobs at GitHub, however, as apparently not all the macOS
> platforms have this flag defined.

Interesting.  https://en.wikipedia.org/wiki/MacOS_version_history says
macOS 14 (Sonoma) was released 2023-09-26, i.e. more than eight months
after the patch.  And the oldest regex(3) man page I could find also
mentions REG_ENHANCED:

https://man.freebsd.org/cgi/man.cgi?query=regex&apropos=0&sektion=0&manpath=macOS+10.12.0&format=html

René

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Junio C Hamano]

René Scharfe <l.s.r@web.de> writes:

> On 3/19/26 11:37 PM, Junio C Hamano wrote:
>> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,
>> 2023-01-08) started to use the REG_ENHANCED option when ERE is not
>> in use on macOS.  The build seems to have started failing on
>> macos-14 CI jobs at GitHub, however, as apparently not all the macOS
>> platforms have this flag defined.
>
> Interesting.  https://en.wikipedia.org/wiki/MacOS_version_history says
> macOS 14 (Sonoma) was released 2023-09-26, i.e. more than eight months
> after the patch.  And the oldest regex(3) man page I could find also
> mentions REG_ENHANCED:
>
> https://man.freebsd.org/cgi/man.cgi?query=regex&apropos=0&sektion=0&manpath=macOS+10.12.0&format=html

Well, I have no idea where this breakage came from; it suddenly
started in today's pushout, and I do not think we have made any
changes on our end to cause it.

E.g.,
https://github.com/git/git/actions/runs/23315793655/job/67814861386#step:4:301

In any case, in the same CI run, a few other jobs on osx- that uses
the same macos-14 image seem to be passing, so I am reasonably sure
that the posted patch is a *bad* idea.  Instead of forcing us to
figure out why REG_ENHANCED is missing, it would just hide the
problem under the rug, possibly breaking a random regex tests that
happen to depend on the "enhanced mode" working. X-<.

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]

Hi Junio,

On Fri, 20 Mar 2026, Junio C Hamano wrote:

> René Scharfe <l.s.r@web.de> writes:
> 
> > On 3/19/26 11:37 PM, Junio C Hamano wrote:
> >> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,
> >> 2023-01-08) started to use the REG_ENHANCED option when ERE is not
> >> in use on macOS.  The build seems to have started failing on
> >> macos-14 CI jobs at GitHub, however, as apparently not all the macOS
> >> platforms have this flag defined.
> >
> > Interesting.  https://en.wikipedia.org/wiki/MacOS_version_history says
> > macOS 14 (Sonoma) was released 2023-09-26, i.e. more than eight months
> > after the patch.  And the oldest regex(3) man page I could find also
> > mentions REG_ENHANCED:
> >
> > https://man.freebsd.org/cgi/man.cgi?query=regex&apropos=0&sektion=0&manpath=macOS+10.12.0&format=html
> 
> Well, I have no idea where this breakage came from; it suddenly
> started in today's pushout, and I do not think we have made any
> changes on our end to cause it.
> 
> E.g.,
> https://github.com/git/git/actions/runs/23315793655/job/67814861386#step:4:301
> 
> In any case, in the same CI run, a few other jobs on osx- that uses
> the same macos-14 image seem to be passing, so I am reasonably sure
> that the posted patch is a *bad* idea.  Instead of forcing us to
> figure out why REG_ENHANCED is missing, it would just hide the
> problem under the rug, possibly breaking a random regex tests that
> happen to depend on the "enhanced mode" working. X-<.

I also hit this in Git for Windows' "ever-green" branches:
https://github.com/git-for-windows/git/actions/runs/23325790048/attempts/1

THe curious thing is that it only hits `osx-clang` and `osx-reftable`, but
not `osx-gcc` nor `osx-meson`.

The breakage coincides with a runner image version bump: if you expand the
"Set up job" step, and within that step also expand the "Runner Image"
group, you will see that the succeeding (older) jobs use 20260302.0147.1,
the failing (newer) jobs use 20260317.0174.1. The change that strikes me
as most likely to be the culprit is the Homebrew bump 5.0.15 -> 5.1.0:
  https://github.com/actions/runner-images/compare/macos-14-arm64/20260302.0147..macos-14-arm64/20260317.0174#diff-5c04a529d3c8adf7a5f23afe544071dad1853e281c9c7b44cd8d626b6c57444dL35-R35

Now, 3 of the 4 `osx-*` jobs use `clang`, only `osx-gcc` uses `gcc`. So my
money is on a clang update in Homebrew disabling support for
`REG_ENHANCED`. But why is `osx-meson` not affected, it uses `clang`?
Well, there's special handling for that in `meson.build`:
https://gitlab.com/git-scm/git/-/blob/v2.53.0/meson.build#L1347-1350

  if compiler.get_define('REG_ENHANCED', prefix: '#include <regex.h>') != ''
    libgit_c_args += '-DUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS'
    libgit_sources += 'compat/regcomp_enhanced.c'
  endif

I'll continue looking along these lines.

Ciao,
Johannes

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Hi,

On Fri, 20 Mar 2026, Johannes Schindelin wrote:

> On Fri, 20 Mar 2026, Junio C Hamano wrote:
> 
> > René Scharfe <l.s.r@web.de> writes:
> > 
> > > On 3/19/26 11:37 PM, Junio C Hamano wrote:
> > >> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,
> > >> 2023-01-08) started to use the REG_ENHANCED option when ERE is not
> > >> in use on macOS.  The build seems to have started failing on
> > >> macos-14 CI jobs at GitHub, however, as apparently not all the macOS
> > >> platforms have this flag defined.
> > >
> [...] my money is on a clang update in Homebrew disabling support for
> `REG_ENHANCED`. But why is `osx-meson` not affected, it uses `clang`?
> Well, there's special handling for that in `meson.build`:
> https://gitlab.com/git-scm/git/-/blob/v2.53.0/meson.build#L1347-1350
> 
>   if compiler.get_define('REG_ENHANCED', prefix: '#include <regex.h>') != ''
>     libgit_c_args += '-DUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS'
>     libgit_sources += 'compat/regcomp_enhanced.c'
>   endif

And it looks indeed as if the `osx-meson` job picks up a difference and
works around it. Last week, it detected `REG_ENHANCED`:
https://github.com/git-for-windows/git/actions/runs/22920658960/job/66517862315#step:4:168

>  Fetching value of define "REG_ENHANCED" : 0400

This week, it detects the absence:
https://github.com/git-for-windows/git/actions/runs/23325790048/job/67846594275#step:4:173

> Fetching value of define "REG_ENHANCED" : (undefined)

So there you have it. One week, the `regex.h` headers defined
`REG_ENHANCED`, the next week, they didn't.

Ciao,
Johannes

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Johannes Schindelin]

Hi Junio,

On Fri, 20 Mar 2026, Junio C Hamano wrote:

> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,
> 2023-01-08) started to use the REG_ENHANCED option when ERE is not
> in use on macOS.  The build seems to have started failing on
> macos-14 CI jobs at GitHub, however, as apparently not all the macOS
> platforms have this flag defined.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  compat/regcomp_enhanced.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/compat/regcomp_enhanced.c b/compat/regcomp_enhanced.c
> index 84193ce53b..51e1358170 100644
> --- a/compat/regcomp_enhanced.c
> +++ b/compat/regcomp_enhanced.c
> @@ -3,7 +3,9 @@
>  
>  int git_regcomp(regex_t *preg, const char *pattern, int cflags)
>  {
> +#ifdef REG_ENHANCED
>  	if (!(cflags & REG_EXTENDED))
>  		cflags |= REG_ENHANCED;
> +#endif

While this lets the build pass, it _does_ change behavior. Where
previously, EREs were enforced, now BREs are silently enforced.

So it might be desirable to instead imitate what `meson.build` does,
namely define `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` on macOS when
compiling with `clang`.

But that should already be the case:
https://gitlab.com/git-scm/git/-/blob/v2.53.0/config.mak.uname#L151

> ifeq ($(uname_S),Darwin)
> [...]
> 	USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease

So: hmm.

Ciao,
Johannes

>  	return regcomp(preg, pattern, cflags);
>  }
> -- 
> 2.53.0-816-g44373249a2
> 
> 
> 

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Johannes Schindelin]

Me again,

On Fri, 20 Mar 2026, Johannes Schindelin wrote:

> On Fri, 20 Mar 2026, Junio C Hamano wrote:
> 
> > Earlier, 54463d32 (use enhanced basic regular expressions on macOS,
> > 2023-01-08) started to use the REG_ENHANCED option when ERE is not
> > in use on macOS.  The build seems to have started failing on
> > macos-14 CI jobs at GitHub, however, as apparently not all the macOS
> > platforms have this flag defined.
> > 
> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
> > ---
> >  compat/regcomp_enhanced.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/compat/regcomp_enhanced.c b/compat/regcomp_enhanced.c
> > index 84193ce53b..51e1358170 100644
> > --- a/compat/regcomp_enhanced.c
> > +++ b/compat/regcomp_enhanced.c
> > @@ -3,7 +3,9 @@
> >  
> >  int git_regcomp(regex_t *preg, const char *pattern, int cflags)
> >  {
> > +#ifdef REG_ENHANCED
> >  	if (!(cflags & REG_EXTENDED))
> >  		cflags |= REG_ENHANCED;
> > +#endif
> 
> While this lets the build pass, it _does_ change behavior. Where
> previously, EREs were enforced, now BREs are silently enforced.
> 
> So it might be desirable to instead imitate what `meson.build` does,
> namely define `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` on macOS when
> compiling with `clang`.
> 
> But that should already be the case:
> https://gitlab.com/git-scm/git/-/blob/v2.53.0/config.mak.uname#L151
> 
> > ifeq ($(uname_S),Darwin)
> > [...]
> > 	USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease
> 
> So: hmm.

Ah. That flag _is_ the reason for the build error: I misunderstood what it
is about. It is not telling the build process to compile with
`compat/regex.c` and using enhanced regexes, it is telling the build
process that whatever regex library is used _does_ support them.

So I need to pivot and recommend something like this in the `Darwin`
clause in `config.mak.uname`:

-- snipsnap --
diff --git a/config.mak.uname b/config.mak.uname
index f9ffefa67a4f..572f8967bc36 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -172,6 +172,10 @@ ifeq ($(uname_S),Darwin)
 		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
         endif
 
+	ifeq ($(CC),clang)
+		NO_REGEX = HomebrewsClangSeemsToBeMissingEnhancedRegexSupportAsOfMarch2026
+	endif
+
 	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require
 	# Unix domain sockets and PThreads.
         ifndef NO_PTHREADS

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Johannes Schindelin]

Me again, sorry,

On Fri, 20 Mar 2026, Johannes Schindelin wrote:

> On Fri, 20 Mar 2026, Johannes Schindelin wrote:
> 
> > On Fri, 20 Mar 2026, Junio C Hamano wrote:
> > 
> > > The build seems to have started failing on macos-14 CI jobs at
> > > GitHub, however, as apparently not all the macOS platforms have this
> > > flag defined.
> 
> [... I need to ...] recommend something like this in the `Darwin` clause
> in `config.mak.uname`:
> 
> -- snipsnap --
> diff --git a/config.mak.uname b/config.mak.uname
> index f9ffefa67a4f..572f8967bc36 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -172,6 +172,10 @@ ifeq ($(uname_S),Darwin)
>  		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
>          endif
>  
> +	ifeq ($(CC),clang)
> +		NO_REGEX = HomebrewsClangSeemsToBeMissingEnhancedRegexSupportAsOfMarch2026
> +	endif
> +
>  	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require
>  	# Unix domain sockets and PThreads.
>          ifndef NO_PTHREADS

Turns out that my analysis was not _quite_ complete yet. With Claude Opus'
assistance, I was able to find the exact turn of events that led to the CI
failure. Here is my proposal for an alternative to your patch, Junio (the
https://github.com/git-for-windows/git/actions/runs/23335584918 shows that
the build completed successfully this time; the tests are still running as
of time of writing, of course):

-- snipsnap --
From f65b3b657c36e9132624ea223c90047527edea59 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Fri, 20 Mar 2026 09:09:10 +0100
Subject: [PATCH] osx-clang: work around Homebrew's clang lacking REG_ENHANCED

The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:

    compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
    'REG_ENHANCED'

The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`.  The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.

Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
https://github.com/Homebrew/brew/pull/21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/).  The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`.  Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`.  Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.

The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4).  The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.

Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12.  The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.

The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.

Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one.  This sidesteps the missing `REG_ENHANCED` define entirely.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/config.mak.uname b/config.mak.uname
index e6efd0f30913..c437accbcc50 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -162,6 +162,17 @@ ifeq ($(uname_S),Darwin)
 		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
         endif
 
+	# Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED,
+	# which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above.
+	# Use our bundled regex instead.  This became a practical problem
+	# when Homebrew 5.1.0 started auto-linking versioned keg-only
+	# formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing
+	# CC=clang in CI to silently pick up Homebrew's clang instead of
+	# Apple's /usr/bin/clang.
+	ifeq ($(CC),clang)
+		NO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED
+	endif
+
 	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require
 	# Unix domain sockets and PThreads.
         ifndef NO_PTHREADS
-- 
2.52.0.windows.1.12.g00d4f5e7d9c

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[René Scharfe]

On 3/20/26 9:55 AM, Johannes Schindelin wrote:
> Me again, sorry,
> 
> On Fri, 20 Mar 2026, Johannes Schindelin wrote:
> 
>> On Fri, 20 Mar 2026, Johannes Schindelin wrote:
>>
>>> On Fri, 20 Mar 2026, Junio C Hamano wrote:
>>>
>>>> The build seems to have started failing on macos-14 CI jobs at
>>>> GitHub, however, as apparently not all the macOS platforms have this
>>>> flag defined.
>>
>> [... I need to ...] recommend something like this in the `Darwin` clause
>> in `config.mak.uname`:
>>
>> -- snipsnap --
>> diff --git a/config.mak.uname b/config.mak.uname
>> index f9ffefa67a4f..572f8967bc36 100644
>> --- a/config.mak.uname
>> +++ b/config.mak.uname
>> @@ -172,6 +172,10 @@ ifeq ($(uname_S),Darwin)
>>  		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
>>          endif
>>  
>> +	ifeq ($(CC),clang)
>> +		NO_REGEX = HomebrewsClangSeemsToBeMissingEnhancedRegexSupportAsOfMarch2026
>> +	endif
>> +
>>  	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require
>>  	# Unix domain sockets and PThreads.
>>          ifndef NO_PTHREADS
> 
> Turns out that my analysis was not _quite_ complete yet. With Claude Opus'
> assistance, I was able to find the exact turn of events that led to the CI
> failure. Here is my proposal for an alternative to your patch, Junio (the
> https://github.com/git-for-windows/git/actions/runs/23335584918 shows that
> the build completed successfully this time; the tests are still running as
> of time of writing, of course):
> 
> -- snipsnap --
> From f65b3b657c36e9132624ea223c90047527edea59 Mon Sep 17 00:00:00 2001
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> Date: Fri, 20 Mar 2026 09:09:10 +0100
> Subject: [PATCH] osx-clang: work around Homebrew's clang lacking REG_ENHANCED
> 
> The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
> with:
> 
>     compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
>     'REG_ENHANCED'
> 
> The failure coincides with the GitHub Actions `macos-14-arm64` runner
> image being updated from `20260302.0147` to `20260317.0174`.  The key
> change in that image update is the Homebrew version bump from 5.0.15 to
> 5.1.0.
> 
> Homebrew 5.1.0 introduced automatic linking for versioned keg-only
> formulae when the unversioned sibling is absent (see
> https://github.com/Homebrew/brew/pull/21676, announced at
> https://brew.sh/2026/03/10/homebrew-5.1.0/).  The runner image installs
> `llvm@15` (keg-only) but not unversioned `llvm`.  Under Homebrew 5.0.x
> that formula stayed in its keg and its `clang` binary only lived at
> `$(brew --prefix llvm@15)/bin/clang`.  Under 5.1.0, because unversioned
> `llvm` is absent, `llvm@15` is now auto-linked into
> `/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
> 
> The net effect is that `CC=clang` in CI now silently resolves to
> Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
> clang 15.0.0, bundled with Xcode 15.4).  The runner image README
> confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
> 15.0.7 between image releases, matching the Homebrew LLVM version
> exactly.

Good find!

> Homebrew's LLVM clang uses different include paths from Apple's clang.
> In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
> which is an Apple-specific extension present in the macOS SDK headers
> since at least macOS 10.12.  The Makefile unconditionally sets
> `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
> `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
> references `REG_ENHANCED`, hence the build failure.

I suspect it uses the same regex.h.  The definition of REG_ENHANCED is
gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails
because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as
__ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not
defined by the Homebrew version of clang in the runner.

I can't reproduce this locally, by the way.
/opt/homebrew/Cellar/llvm/22.1.1/bin/clang is not linked to
/opt/homebrew/bin on my machine and also provides a sensible definition
of __MAC_OS_X_VERSION_MIN_REQUIRED.

> The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
> configured to use Apple's SDK sysroot, so it still picks up Apple's
> `regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is
> unaffected because Meson does a compile-time test for `REG_ENHANCED`
> (via `compiler.get_define`) and simply skips the feature when it is
> absent.
> 
> Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
> makes the build use Git's bundled regex implementation instead of the
> system one.  This sidesteps the missing `REG_ENHANCED` define entirely.

Or how about using /usr/bin/clang explicitly on macOS instead of any old
clang from $PATH?  That would avoid user-visible changes.

> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  config.mak.uname | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/config.mak.uname b/config.mak.uname
> index e6efd0f30913..c437accbcc50 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -162,6 +162,17 @@ ifeq ($(uname_S),Darwin)
>  		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
>          endif
>  
> +	# Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED,
> +	# which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above.
> +	# Use our bundled regex instead.  This became a practical problem
> +	# when Homebrew 5.1.0 started auto-linking versioned keg-only
> +	# formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing
> +	# CC=clang in CI to silently pick up Homebrew's clang instead of
> +	# Apple's /usr/bin/clang.
> +	ifeq ($(CC),clang)
> +		NO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED
> +	endif
> +
>  	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require
>  	# Unix domain sockets and PThreads.
>          ifndef NO_PTHREADS

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 3711 bytes --]

Hi René,

On Fri, 20 Mar 2026, René Scharfe wrote:

> On 3/20/26 9:55 AM, Johannes Schindelin wrote:
> 
> > Homebrew's LLVM clang uses different include paths from Apple's clang.
> > In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
> > which is an Apple-specific extension present in the macOS SDK headers
> > since at least macOS 10.12.  The Makefile unconditionally sets
> > `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
> > `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
> > references `REG_ENHANCED`, hence the build failure.
> 
> I suspect it uses the same regex.h.  The definition of REG_ENHANCED is
> gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails
> because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as
> __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not
> defined by the Homebrew version of clang in the runner.

That makes sense! I couldn't investigate this because I do not have a
local macOS setup to test with, and I did not want to abuse GitHub
Actions' runners (nor did I want to spend more of my own time on the
investigation).

> I can't reproduce this locally, by the way.
> /opt/homebrew/Cellar/llvm/22.1.1/bin/clang is not linked to
> /opt/homebrew/bin on my machine and also provides a sensible definition
> of __MAC_OS_X_VERSION_MIN_REQUIRED.

Hmm. I am convinced, though, that if it hits CI, it hits human users as
well. Maybe the difference is that you upgraded from an existing setup
while the runners (I think) are built from scratch every time.

> > The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
> > configured to use Apple's SDK sysroot, so it still picks up Apple's
> > `regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is
> > unaffected because Meson does a compile-time test for `REG_ENHANCED`
> > (via `compiler.get_define`) and simply skips the feature when it is
> > absent.
> > 
> > Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
> > makes the build use Git's bundled regex implementation instead of the
> > system one.  This sidesteps the missing `REG_ENHANCED` define entirely.
> 
> Or how about using /usr/bin/clang explicitly on macOS instead of any old
> clang from $PATH?  That would avoid user-visible changes.

That would fix our CI runs, but it would expose users who set their `CC =
clang` to the same problem that broke our CI builds...

Ciao,
Johannes

> 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  config.mak.uname | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/config.mak.uname b/config.mak.uname
> > index e6efd0f30913..c437accbcc50 100644
> > --- a/config.mak.uname
> > +++ b/config.mak.uname
> > @@ -162,6 +162,17 @@ ifeq ($(uname_S),Darwin)
> >  		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
> >          endif
> >  
> > +	# Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED,
> > +	# which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above.
> > +	# Use our bundled regex instead.  This became a practical problem
> > +	# when Homebrew 5.1.0 started auto-linking versioned keg-only
> > +	# formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing
> > +	# CC=clang in CI to silently pick up Homebrew's clang instead of
> > +	# Apple's /usr/bin/clang.
> > +	ifeq ($(CC),clang)
> > +		NO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED
> > +	endif
> > +
> >  	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require
> >  	# Unix domain sockets and PThreads.
> >          ifndef NO_PTHREADS
> 
> 
> 

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[René Scharfe]

On 3/20/26 4:12 PM, Johannes Schindelin wrote:
> Hi René,
> 
> On Fri, 20 Mar 2026, René Scharfe wrote:
> 
>> On 3/20/26 9:55 AM, Johannes Schindelin wrote:
>>
>>> Homebrew's LLVM clang uses different include paths from Apple's clang.
>>> In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
>>> which is an Apple-specific extension present in the macOS SDK headers
>>> since at least macOS 10.12.  The Makefile unconditionally sets
>>> `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
>>> `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
>>> references `REG_ENHANCED`, hence the build failure.
>>
>> I suspect it uses the same regex.h.  The definition of REG_ENHANCED is
>> gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails
>> because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as
>> __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not
>> defined by the Homebrew version of clang in the runner.
> 
> That makes sense! I couldn't investigate this because I do not have a
> local macOS setup to test with, and I did not want to abuse GitHub
> Actions' runners (nor did I want to spend more of my own time on the
> investigation).
> 
>> I can't reproduce this locally, by the way.
>> /opt/homebrew/Cellar/llvm/22.1.1/bin/clang is not linked to
>> /opt/homebrew/bin on my machine and also provides a sensible definition
>> of __MAC_OS_X_VERSION_MIN_REQUIRED.
> 
> Hmm. I am convinced, though, that if it hits CI, it hits human users as
> well. Maybe the difference is that you upgraded from an existing setup
> while the runners (I think) are built from scratch every time.

Here's an experiment: This command:

   printf "%s\n" "#include <regex.h>" __MAC_OS_X_VERSION_MIN_REQUIRED REG_ENHANCED | clang -E -

... prints the preprocessed regex.h on a macos-14 runner (from the macOS
SDK, good) as well as the resolved values of the two macros (140000 and
0400).

Calling make instead of ci/run-build-and-tests.sh lets the build succeed,
including compat/regcomp_enhanced.o.

So the plain runner is doing fine?

>>> The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
>>> configured to use Apple's SDK sysroot, so it still picks up Apple's
>>> `regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is
>>> unaffected because Meson does a compile-time test for `REG_ENHANCED`
>>> (via `compiler.get_define`) and simply skips the feature when it is
>>> absent.
>>>
>>> Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
>>> makes the build use Git's bundled regex implementation instead of the
>>> system one.  This sidesteps the missing `REG_ENHANCED` define entirely.
>>
>> Or how about using /usr/bin/clang explicitly on macOS instead of any old
>> clang from $PATH?  That would avoid user-visible changes.
> 
> That would fix our CI runs, but it would expose users who set their `CC =
> clang` to the same problem that broke our CI builds...
I still don't get it, but below are two fixes; either works (i.e. only
one of the two files needs to be changed).  But why?  $CUSTOM_PATH only
contains p4 and p4d.  My observations don't make much sense, I must be
looking at it wrong. :-|

René


 .github/workflows/main.yml | 6 +++---
 ci/lib.sh                  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 826f2f5d3a..f8c6e034ee 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -322,16 +322,16 @@ jobs:
       matrix:
         vector:
           - jobname: osx-clang
-            cc: clang
+            cc: /usr/bin/clang
             pool: macos-14
           - jobname: osx-reftable
-            cc: clang
+            cc: /usr/bin/clang
             pool: macos-14
           - jobname: osx-gcc
             cc: gcc-13
             pool: macos-14
           - jobname: osx-meson
-            cc: clang
+            cc: /usr/bin/clang
             pool: macos-14
     env:
       CC: ${{matrix.vector.cc}}
diff --git a/ci/lib.sh b/ci/lib.sh
index 42a2b6a318..6310c16b7a 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -346,7 +346,7 @@ macos-*)
 esac
 
 CUSTOM_PATH="${CUSTOM_PATH:-$HOME/path}"
-export PATH="$CUSTOM_PATH:$PATH"
+export PATH="$PATH:$CUSTOM_PATH"
 
 case "$jobname" in
 linux32)

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Junio C Hamano]

René Scharfe <l.s.r@web.de> writes:

>> The net effect is that `CC=clang` in CI now silently resolves to
>> Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
>> clang 15.0.0, bundled with Xcode 15.4).  The runner image README
>> confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
>> 15.0.7 between image releases, matching the Homebrew LLVM version
>> exactly.
>
> Good find!

Indeed.  So clang got updated pretty recently (CI runs triggered by
my pushing out happens at least once a day and yesterday was the
first time I saw this failure), and that is because Homebrew got
updated?

>> Homebrew's LLVM clang uses different include paths from Apple's clang.
>> In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
>> which is an Apple-specific extension present in the macOS SDK headers
>> since at least macOS 10.12.  The Makefile unconditionally sets
>> `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
>> `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
>> references `REG_ENHANCED`, hence the build failure.
>
> I suspect it uses the same regex.h.  The definition of REG_ENHANCED is
> gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails
> because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as
> __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not
> defined by the Homebrew version of clang in the runner.

> Or how about using /usr/bin/clang explicitly on macOS instead of any old
> clang from $PATH?  That would avoid user-visible changes.

If it gives us more stability of CI environment (one fewer thing
that can suddenly change the toolset), and makes the environment
closer to a typical end-user set-up (hopefully most of them would
use what is available in /usr/bin from there, instead of downloading
newer versions but possibly built with different/castrated set of
features), that does look like an attractive alternative to me.

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> While this lets the build pass, it _does_ change behavior. Where
> previously, EREs were enforced, now BREs are silently enforced.

Enhanced is not about ERE/BRE but yes, you're right.  A build that
does not support REG_ENHANCED (due to the lack of definition in the
header) would compile but without enhanced features like \b, so the
"patch" above would not something I want to apply and blamed by
macOS users for X-<.

> So it might be desirable to instead imitate what `meson.build` does,
> namely define `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` on macOS when
> compiling with `clang`.
>
> But that should already be the case:
> https://gitlab.com/git-scm/git/-/blob/v2.53.0/config.mak.uname#L151
>
>> ifeq ($(uname_S),Darwin)
>> [...]
>> 	USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease
>
> So: hmm.

Hmm, indeed.

Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
> makes the build use Git's bundled regex implementation instead of the
> system one.  This sidesteps the missing `REG_ENHANCED` define entirely.

While this may make things built identically between CI environment
and end-user environment, do we have to worry about what we lose by
not using system supplied regex library?

If the answer is "no, we do not lose anything, and even if we do,
that's miniscule loss that does not matter", then I like the
approach.

I wonder if we could do something like this instead?

	ifeq ($(CC),clang)
		CC := /usr/bin/clang
	eneidf

as was suggested in one of the downthread messages by René?

Thanks.