On Fri, May 22, 2020 at 02:31:38PM +0200, Mark Kettenis wrote: > > 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.
>From a security standpoint, is there a "cheap" way to make setlocale abort() instead of trying to do a double free on when running in a race condition ? > > 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() ;). Well, I had a look at the current code, they changed it yet again, so it's probably going to fail in newer, more funny ways.
