[libcxx Windows][PATCH] uselocale change.

Dev Dude devdude2 at hotmail.com
Sat Mar 23 02:02:13 PDT 2013


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.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130323/d26ad2a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: locale_win32.null.cpp.diff
Type: application/octet-stream
Size: 593 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130323/d26ad2a5/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130323/d26ad2a5/attachment-0001.html>


More information about the cfe-commits mailing list