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

[Ruben Van Boxem]

2011/6/30 Ruben Van Boxem <vanboxem.ruben at gmail.com>

> 2011/6/30 Howard Hinnant <hhinnant at apple.com>:
> >
> > On Jun 28, 2011, at 3:15 PM, Ruben Van Boxem wrote:
> >
> >> This is a larger patch with a bit more changes. I added a
> >> win32/support.h/cpp to add any missing functionality. For now that's
> >> only a simple enum and a simple vasprintf implementation.
> >>
> >> Note that to get as far as this, with the current _STD macro problem
> >> (because it is used internally in the MS headers), you need to add a
> >> temporary workaround #define in the problematic file. That does not
> >> have to be committed!
> >
> > I'll just change _STD to _VSTD (versioned std).  Is _VSTD already taken
> on windows?
>
> a "grep -r "_VSTD" ." in the MSVC 10 include directory, the mingw-w64
> include directory, and the Windows SDK v7.1 include directory turned
> up no results, so this should be fine.
>
> >
> >>
> >> The cerrno macro's are from Boost, so "yes, they are correct", and
> >> "no, there are no license restrictions whatsoever". The _strto*_l
> >> functions are available on Windows msvcrt version 7. That's the
> >> default somewhere Vista/7-ish, so those aren't available on XP. I
> >> believe the Linux locale patch also takes into consideration providing
> >> a Windows alternative with little or no modification.
> >
> > These constants appear to me to be public knowledge (i.e. no copyright
> issues).
>
> Good to know. Although the bottom of the mingw-w64 header here
>
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/include/psdk_inc/_wsa_errnos.h?revision=3546&view=markup
> seems to imply there are more sensible defines (without that many
> magic numbers, mostly to WSAE* codes which ought to come from
> <winsock2.h>). I cannot judge the difference though...
>
> >
> >>
> >> I'm quite sure the win32/support.h/cpp isn't the nicest solution,
> >> please do as you wish, there just needs to be a central place to add
> >> missing fundamental functionality. Perhaps a larger splitting of OS
> >> dependent functionality might be appropriate in the future.
> >>
> >> As of with this patch (which includes the _STD clash workaround, I am
> >> now stranded at the catopen call in __locale, which as a little
> >> googling shows is very non-Windows-ish, and perhaps needs a lot more
> >> than just extra constants, #defines and #includes.
> >>
> >> I would be pleased if anyone would commit at least the part of it they
> like :)
> >
> > Let me commit the _STD -> _VSTD first, and then create a new patch using
> that.
>
> Thanks! I'd like to do more, but I think I've reached my knowledge and
> capability limits. Some Windows guru (or even better, a Windows C++
> guru) will have to step up and implement more of libc++ to be usable.
> Remember that the _strto*_l functions are very new, and most probably
> don't work on XP, and may not work on Vista. I look to the Linux patch
> on this and *hope* it is general/compatible enough to work without
> much modification on Windows as well.
>

I have finally gotten to more libc++ Windows work, and attached is a patch
that addresses some of the issues that pop up. I know it's a lot to take in,
but most changes are pretty logical (or I wouldn't have been able to
find/code them). I'm currently facing implementing  wcsnrtombs and after
that there's the more troubling issue of catgets and associates, which I'm
quite worried about, as Win32 is almost orthogonal to this whole API. Ideas
for that are very welcome.

The patch explained:
- include/__config/type_traits: add a define _LIBCXX_HAS_FEATURE_IS_BASE_OF
for MSVC and GCC, which both have this, but not __has_feature, which is
Clang-only. Modify <type_traits> accordingly.
 - include/locale: Win32 does not have nl_types, which really sucks... big
time.
 - include/cerrno: the missing error constants, very much acceptable as said
by Howard in this thread some time ago.
 - include/__locale: include the new support/win32/locale.h header, and
leave out the missing xlocale.h. Maybe a stupid name, but I haven't found a
better name for it. Maybe once the whole win32 stuff is complete, some
refactoring is in order. The mask type is defined and all values are defined
to the correct values (extracted from mingw-w64 headers).
 - include/support/win32/support.h: a place for missing functions'
declarations to live.
 - include/support/win32/locale.h: locale-related stuff (duh!) missing or
otherwise defined in Win32 headers.
 - CMakeLists.txt: add the new files, only on Win32.
 - src/support/win32/support.cpp: implementation of functions in
include/support/win32/support.h.

All this should work for both MinGW(-w64)/GCC and Microsoft/MSVC
headers/libraries. Note the *_l functions are only available on recent
Windows versions, which should be good enough for now. Especially the locale
stuff (up till now!) should work for more than only plain "C" locale.

One point of attention: the FIXME in the new locale.h header needs
attention: Win32 needs to call a function to enable thread-local locales,
and then setlocale operates on the thread's locale, which is great. But this
function needs to be called somewhere before everything else (in some static
initialization function or something). On top of that, I'm not quite sure
that what I do in my short implementation of uselocale is correct. I think
it is, and it definitely is inefficient.

I tested this on GCC and Clang built for mingw-w64.

Please review and commit if you're OK. Thanks!

Ruben

PS: any further help is very much appreciated!


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