Re: PostgreSQL does not compile on macOS SDK 15.0

On Wed, Jun 26, 2024 at 2:39 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think the immediate action item should be to push back on the
> change and see if we can get Apple to undo it. If we have to
> fix it on our side, it is likely to involve API-breaking changes
> that will cause trouble for extensions. The more so because
> we'll have to change stable branches too.

I am struggling to understand why they would consider such a request.
POSIX reserves *_t, and then regex_t et al explicitly, and I don't see
why Apple isn't allowed to have arbitrary transitive inclusions across
system headers... AFIACT nothing in POSIX or C restricts that (?).
Any system could have the same problem. It's only a coincidence that
we got away with it before because apparently other OSes don't pull in
the system regex-related definitions from anything that we include,
except macOS which previously happened to use the same include guards
scheme. I guess you could write PostgreSQL extensions (or TCL
programs) that could crash due to using bad struct definitions on
earlier SDK versions depending on whether you included <regex.h> or
PostgreSQL headers first?

Amusingly, those matching include guards probably came from the same
keyboard (Apple's regex code is an earlier strain of Henry Spencer's
regex code, from 4.4BSD). FreeBSD et al have it too. FreeBSD also
has an xlocale.h "extended locale" header (which came back from
Apple), though on FreeBSD it is automatically included by <locale.h>,
because that "extended" locale stuff became standard issue basic
locale support in POSIX 2008, it's just that Apple hasn't got around
to tidying that up yet so they still force us to include <xlocale.h>
explicitly (now *that* is material for a bug report)...

If you look at the header[1], you can see the mechanism for pulling in
a ton of other stuff: <xlocale.h> wants to activate all the _l
functions, so it runs around including xlocale/_EVERYTHING.h. For
example xlocale/_string.h adds strcoll_l(..., locale_t), and
xlocale/_regex.h adds regcomp_l(..., locale_t), etc etc. Which all
seems rather backwards from our vantage point where locale_t is
standard and those should ideally have been declared in the "primary"
header when people actually wanted them and explicitly said so by
including eg <string.h>. So why doesn't FreeBSD have the same
problem? Just because it doesn't actually have reg*_l() functions...
yet. But it will, there is talk of adding the complete set of every
imaginable _l function to POSIX. So FreeBSD might eventually add
xlocale/_regex.h to that header explosion (unless someone does the
completely merge/tidy-up I imagined above, which I might suggest).
Perhaps in the fullness of time Apple will also do a similar clean-up,
so that xlocale.h goes away, but I wouldn't hold my breath.

I don't have any great ideas about what to do about this.
Cybersquatting system facilities is a messy business, so maybe the
proposed grotty solution is actually appropriate! We did bring this
duelling Henry Spencers problem upon ourselves. Longer term,
pg_regex_t seems to make a lot of sense, except IIUC we want to keep
this code in sync with TCL so perhaps a configurable prefix could be
done with macrology?

[1] https://github.com/apple-oss-distributions/Libc/blob/main/include/xlocale.h