Hi Ken,
On 3/20/19 10:11 PM, Ken Thomases wrote:
As it turns out, the macOS implementation works differently than Linux/POSIX. Maybe that's common to BSDs generally, I don't know.
In macOS's C library, the thread locale is freed on thread exit, for all threads. The thread locale is stored in a thread-specific key with a destructor. There is some internal reference counting, but the locale object itself is freed unconditionally so that doesn't help us any. So, my concern about leaking was misplaced, as was my suggestion to avoid duplicating the locale for every thread. But now there's a concern about glibc.
Also, on macOS, newlocale() never modifies nor frees base. The new locale is always newly-created and independent from base and base is left alone. (Internally, it duplicates base to create the new locale and then modifies it as per the mask and locale string.)
So, global_loc is leaked on macOS.
It's a shame it was not well standardized. It probably makes the function not suitable for us (unless all the other solutions are even worse).
Kind of a mess. :(I've filled a bug to man-pages project regarding newlocale man page.
According to valgrind sample code uses locale after it's being freed :)
Thanks, Piotr