Committed revision 178545. Howard
On Mar 30, 2013, at 11:48 AM, Howard Hinnant <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
