> Date: Fri, 22 May 2020 13:50:44 +0200 > From: Marc Espie <es...@nerim.net> > > I've had to neuter some setlocale() in mlt, since our code is > definitely NOT thread-safe. No biggie, since we do not have support > for LC_NUMERIC right now.
Hmm, setlocale() is explicitly mentionded as not thread-safe in POSIX. > I think we might want the thread-specific functions, namely stuff like > strtod_l, or sprintf_l and friends. That is <xlocale.h>. which isn't actually standardized. But there is a de-facto standard set by Apple. Most OSes have an implementation by now and our libc++ needs it (and uses a stub implementation for now). The Darwin and/or FreeBSD man pages are probably the best documentation for these interfaces. > Even if they do not do anything specific right now with a locale object, > at least they would prevent re-entrency issues. Yes, implementing these shouldn't be hard. We already have wctype_l() and iswctype_l() (which are standardized) which do care about the locale. But everything else probably doesn't so these functions can be simple wrappers around the non-_l functions that simply ignore the locale. It's just work but really doesn't require sepcific skills. I'm sure Ingo will be able to give some constructive feedback once a diff exists. > Note that the current issue is a time-bomb, because it is a race, so > it does only manifest itself as a double free in freegl... > > uselocale is fine, but it is not on windows, so highly portable code > tends to prefer strtod_l... Which is funny since strtod_l is even less standard than uselocale() ;).
