[cfe-dev] [PATCH] Libc++ Windows fixes

[Ruben Van Boxem]

2011/9/29 Ruben Van Boxem <vanboxem.ruben at gmail.com>

> 2011/9/29 Ruben Van Boxem <vanboxem.ruben at gmail.com>
>
>> 2011/9/29 Ruben Van Boxem <vanboxem.ruben at gmail.com>
>>
>>> 2011/9/29 Howard Hinnant <hhinnant at apple.com>
>>>
>>>>
>>>> On Sep 28, 2011, at 6:17 PM, David Chisnall wrote:
>>>>
>>>> > On 28 Sep 2011, at 22:45, Howard Hinnant wrote:
>>>> >
>>>> >> I think FreeBSD should define _LLIBCPP_STABLE_APPLE_ABI too.  David?
>>>>  And maybe with David's latest patch to FreeBSD, should also #define
>>>> _LIBCPP_GET_C_LOCALE 0.
>>>> >
>>>> > FreeBSD should now be mirroring the Apple implementation for anything
>>>> xlocale related.  If there are any discrepancies, they are bugs and I'll fix
>>>> them in libc, rather than hack around them in libc++.
>>>> >
>>>> > I'm not entirely sure what defining _LLIBCPP_STABLE_APPLE_ABI means -
>>>> perhaps it could be replaced with a more descriptive name?
>>>>
>>>> See revision 140734, and let me know what needs fixing (hopefully
>>>> nothing).
>>>>
>>>
>>> This improves the behavior on Windows (uses the C locale instead of
>>> returning NULL like for Linux). Attached patch also removes unreachable code
>>> (_LIBCPP_HAS_DEFAULTRUNELOCALE is defined for both __APPLE__ and
>>> __FreeBSD__, so the additional checks in locale.cpp are never reached).
>>>
>>> I'm now also wondering about _LIBCPP_WCTYPE_IS_MASK. I've been looking at
>>> MSDN, but can't figure out if it matches. I did find a warning that if a
>>> plain "char" is passed to Windows is* functions, unexpected results are
>>> obtained (
>>> http://msdn.microsoft.com/en-us/library/4yc6feha%28v=vs.80%29.aspx). It
>>> seems that char_type could be char in the common case, and this could yield
>>> unreliable behavior?
>>>
>>> Ruben
>>>
>>
>> Never mind this patch. It's broken. Is there any reason not to call plain
>> "toupper" in do_toupper directly? Or at least "toupper_(c,__cloc())"?
>>
>> Ruben
>>
>
> Okay, brace yourself...
>
> I've tried to remove locale.cpp's dependency on glibc's toupper and tolower
> transformation tables, which are only available in glibc. I have coded a
> fallback do_tolower and do_toupper using basic ASCII subtract and add tricks
> if glibc or the DefaultRuneLocale is not available. I know this is slower,
> but it works at least. It uses islower_l and isupper_l with __cloc to check.
> The change in behavior should be:
> Mac: none
> FreeBSD: none
> Linux/glibc: none
> other platforms (including Windows): no __classic_upper/lower_table
> functions declared, defined, or used.
> I also declared a symbol present in msvcrt.dll that represents the mask
> table and added that case to classic_table.
>
> I would prefer having a (global) static "C" locale object that can just be
> given through __cloc, although I don't know if this is safe, but as long as
> __cloc is only used in _l functions (which I think it is), this approach of
> a persistent (global, not function-local) C locale object should work (is
> initialized before any threads could call __cloc at the same time) and fix
> the FIXME in __cloc.
>
> I also tried to fix the ctype<wchar_t>::do_is to keep track of the result,
> and now should work if multiple flags were requested.
>
> Comments welcome!
>

Today is not my day. Right patch is attached, with missing bits included
this time. After this, I'm taking a break, before I spam this list with
broken patches :(


> Ruben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110929/b08206cc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: windows.patch
Type: application/octet-stream
Size: 8697 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110929/b08206cc/attachment.obj>