On Wed, Jun 26, 2024 at 2:39 AM Tom Lane <t...@sss.pgh.pa.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