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

David Chisnall csdavec at swan.ac.uk
Sun Sep 25 14:45:14 PDT 2011


On 25 Sep 2011, at 22:30, Howard Hinnant wrote:

> I think it is getting time for a refactoring in <locale>.
> 
> What appears to be happening is that functions like asprintf_l are getting implemented for each platform, which I think is a good thing.  But it appears to be happening in an increasingly convoluted way.  For example we have:
> 
> #ifdef _LIBCPP_STABLE_APPLE_ABI
>      __n = asprintf_l(&__bb, 0, "%.0Lf", __units);
> #else
>      __n = __asprintf_l(&__bb, __cloc(), "%.0Lf", __units);
> #endif

That struck me as a mess when I was trying to follow the code.  

> The first branch is only taken by __APPLE__.  

It should also be taken by FreeBSD, since we now have a complete xlocale implementation.  I'm not sure if it is, because the mess of #ifdefs confused me (and I've no idea what stable Apple ABI is supposed to mean).

> The second branch is taken by everyone else and the definition of __asprintf_l is earlier in <locale>.  This definition sometimes calls vasprintf_l, vasprintf, asprintf, and even (ironically) asprintf_l!  

I don't really understand why this happens.  If you have vasprintf_l(), the odds are that you have asprintf_l() too...

> And it isn't easy (at least to me), to see what is happening on each platform.

Completely agree.

> Suggestion:
> 
> #ifdef __APPLE__
> #   define _LIBCPP_GET_C_LOCALE 0
> #else
> #   define _LIBCPP_GET_C_LOCALE __cloc()
> #endif

I'm not sure what this is for.  0 is not the C locale on Apple, it is the current thread's locale.  From the xlocale(3) man page on Darwin:

> For each of these rou-
> tines, if a NULL locale_t is given, the current locale is used.


If we should be using the C locale, then we should not be using 0 on OS X.  If we should be using the current locale, we should not be using __cloc() anywhere else...

> ...
> 
>   __n = asprintf_l(&__bb, _LIBCPP_GET_C_LOCALE, "%.0Lf", __units);

Yes please!  I already fixed one copy-and-paste bug where the OS X code path was correct but the version in the #else clause was not (and, if we set the proper printf attributes on these printf-analogues, would have been rejected by the compiler.

> And then everyone go off and implement asprintf_l, preferably not in <locale>.  E.g. (and correct me if I'm wrong), __FreeBSD__ has done this in libc.

Yup, FreeBSD (pending code review) has this in libc, just like Darwin.  

> _WIN32 is doing it in src/support/win32/support.cpp.  I'd like to see this block of code:
> 
> // OSX has nice foo_l() functions that let you turn off use of the global
> // locale.  Linux, not so much.  The following functions avoid the locale when
> // that's possible and otherwise do the wrong thing.  FIXME.
> #ifndef _LIBCPP_STABLE_APPLE_ABI
> 
> just disappear, or at the very least become greatly reduced.
> 
> Thoughts?

Sounds good, modulo the queries I've already raised,

David



More information about the cfe-dev mailing list