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

[Ruben Van Boxem]

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


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