[libcxx Windows][PATCH] uselocale change.

[Howard Hinnant]

Committed revision 178545.

Howard

On Mar 30, 2013, at 11:48 AM, Howard Hinnant <hhinnant at apple.com> wrote:

> Below is an anonymously donated patch for libcxx on Windows.  For those interested in libcxx on Windows, please review and recommend either accepting or rejecting this patch.
> 
> Thanks,
> Howard
> 
> ------------------ 
> On my platform, Win32 GCC 4.8 based Mingw64 on Windows 7, NULL is being passed to uselocale crashing *nearly every* application that runs at some point and a good 10-15 files in the libcxx test suite.
> 
> The attached patch is a tiny patch (two lines) to libcxx's support\locale_win32.cpp file that aims to prevent this. The new lines are indicated below by +.
> 
> locale_t uselocale( locale_t newloc )
> {
>    locale_t old_locale = _get_current_locale();
> +    if ( newloc == NULL )
> +        return old_locale;
>    // uselocale sets the thread's locale by definition, so unconditionally use thread-local locale
>    _configthreadlocale( _ENABLE_PER_THREAD_LOCALE );
>    // uselocale sets all categories
>    setlocale( LC_ALL, newloc->locinfo->lc_category[LC_ALL].locale );
>    // uselocale returns the old locale_t
>    return old_locale;
> }
> 
> The effect of this patch is to make uselocale( NULL ) just query the current locale; mirroring what setlocale(NULL) does, so it *seemed* appropriate.
> 
> This patch DOES needs some scrutiny as it is likely not conceptually the correct fix?
> 
> However, if it is NOT the correct fix, in absence of whatever the correct solution is, it needs to be stressed that the effect of this simple patch is soooo significant and positive on the platform for which it is being tested on, that it may be justified in being enabled anyway, perhaps with #if _WIN32 around the new lines, or something like that, until a better fix can be produced.
> 
> Otherwise all my further patches will show zero demonstrable advances in the test suite and it work make working on them and the platform impossible for everyone as it currently appears to be.
> 
> There are 10-15 test cases I intend to get working next with further patches, and are all blighted by multiple problems of which this problem is one of them, and until all the problems get fixed in a test case, it will not pass.
> 
> So as I say, this patch may be incorrect, but unless there is a more correct fix that is reasonably within my ability to produce (help appreciated), it may be better IMHO to go with a wrong fix for this problem here, then none, as far as I can tell or else my following patches will simply show no value and using libcxx on mingw/msvc will continue to be almost impossible for most people.
> 
> I hope I haven't overstated my assessment, but that is how it appears to me today.
> 
> Thoughts appreciated.
> 
> <locale_win32.null.cpp.diff>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits