[cfe-dev] [PATCH] Libc++ Windows fixes (Attention all libc++ ports!!!)

[Howard Hinnant]

On Sep 26, 2011, at 10:08 AM, Ruben Van Boxem wrote:

> 2011/9/26 Howard Hinnant <hhinnant at apple.com>
> On Sep 26, 2011, at 4:38 AM, Ruben Van Boxem wrote:
> 
> > If the __foo_l functions are just the wrappers that they seem to be, I can certainly live with removing this layer of indirection and me implementing the missing functions that are now wrongfully bypassed. I think expecting all xlocale functions to be present is fair for future implementations/ports. This would mean some additions to the support/win32/locale.h header only, which would concentrate any real problems there, which is a good thing. All platform-related fixme's and their future fixes (at least the win32 ones) would go in one centralized place, away from the public libc++ headers and core libc++. Other ports can do the same.
> >
> > In that block of code, there is also a construct
> > __locale_raii __current(uselocale(__l), uselocale);
> >   int __res = sprintf(__s, __format, __args...);
> >
> > Does this do the right thing; a very wasteful implementation of the correct behavior, or is this just an attempt to not make things worse. This would be important for me implementing missing *_l functions. If the above worked like I hope it does, that becomes very easy, albeit unperformant.
> 
> I believe it does the right thing, presuming you have uselocale that sets the per-thread locale to __l.
> 
> That is great news! For this to function correctly, I need to call "_configthreadlocale"  (http://msdn.microsoft.com/en-us/library/26c0tb7x%28v=vs.80%29.aspx) somewhere before anything else, only once. Is there an existing static initialization function in libc++ I could add this call to?
> 
> Thanks!

There isn't a libc++ initialization function.

Perhaps you could add this initialization to __cloc()?

Howard