On Mon, Feb 14, 2022 at 10:00 PM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > During development, I have been using the attached patch to simulate > libc collation versions on macOS. It just uses the internal major OS > version number. I don't know to what the extend the libc locales on > macOS are maintained or updated at all, so I don't know what practical > effect this would have. Again, it's mainly for development. If there > is interest from others, I think we could add this, maybe disabled by > default, or we just keep it in the mailing list archives for interested > parties.
Last time I looked into this it seemed like macOS's strcoll() gave sensible answers in the traditional single-byte encodings, but didn't understand UTF-8 at all so you get C/strcmp() order. In other words there was effectively nothing to version. I remember that other old Unixes used to be like that, and I suspect that they might be using old pre-UTF-8 FreeBSD code for locales based on a quick peek at [1] (though FreeBSD itself has since learned to do CLDR-based UTF-8 sorting with a completely new implementation shared with other OSes). This makes me wonder if Apple is hiding another collation implementation somewhere up its sleeve -- surely that libc support is not good enough for the world's shiny globalised macOS/iOS apps? Maybe UCCompareText() and friends (UnicodeUtilitiesCoreLib) and the various Obj-C NSString comparison stuff, all of which probably predates Unixoid macOS (google tells me that UnicodeUtilities.h was present in macOS 9). It wouldn't be surprising if it shares nothing with the modern OS's C runtime stuff that came via NeXT. Just mentioning this as a curiosity, because I was trying to figure out how that could be left non-working without anyone complaining... [1] https://github.com/apple-open-source-mirror/Libc/tree/master/locale
