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

[Ruben Van Boxem]

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

> 2011/9/22 Ruben Van Boxem <vanboxem.ruben at gmail.com>
>
>> 2011/9/22 Eli Friedman <eli.friedman at gmail.com>
>>
>>> On Thu, Sep 22, 2011 at 12:35 PM, Ruben Van Boxem
>>> <vanboxem.ruben at gmail.com> wrote:
>>> > 2011/9/22 Howard Hinnant <hhinnant at apple.com>
>>> >>
>>> >> Patch committed revision 140328.
>>> >
>>> > Thanks!
>>> >
>>> > Now that I've got your attention, on to more... involved... matters :-)
>>> >
>>> > In order to support libc++'s current implementation using
>>> > cat[gets|open|close] and nl_types.h (which I ignored for now), I would
>>> need
>>> > to pull in some external code, namely mingw's libcatgets and a
>>> supporting
>>> > iconv library. These can all go under support/win32 and leave all other
>>> > platforms unchanged of course, and leave the rest of libc++ as coherent
>>> as
>>> > possible on all platforms. I understand Howard has an acceptable
>>> aversion to
>>> > including too much foreign code in libc++, and hope you can see the
>>> need for
>>> > this here.
>>> >
>>> > There are some issues though:
>>> >  - libcatgets is licensed under GPLv2. If I can go through with this, I
>>> can
>>> > ask/plead/beg the original author to allow a license change or ask him
>>> to
>>> > make an exception for libc++. I know of no existing alternative.
>>> >  - for the iconv part, GNU libiconv is of course out of the question.
>>> There
>>> > are two projects of interest: APR-iconv (Apache License 2.0) and
>>> win-iconv
>>> > (BSD 2-clause license), the latter being tiny but primitive. The first
>>> is a
>>> > truly first class implementation as far as I can see, and with minor
>>> > refactoring could be included in the libc++ Windows build.
>>> >  - I am not an Open Source license lawyer, and do not know what would
>>> be
>>> > acceptable for libc++ in this regard.
>>> >
>>> > I want to ask what's "best", before starting with the implementation.
>>> The
>>> > only real alternative is writing all this (ie catgets with supporting
>>> iconv
>>> > code) from scratch, which I don't see myself doing in the near to
>>> distant
>>> > future. Another way is to completely replace libc++ parts that use/rely
>>> on
>>> > these API's, but this would make libc++ a lot more assymetric across
>>> > platforms. In theory, these support files could help other platforms
>>> where
>>> > these API's are missing.
>>> >
>>> > Please let me know what you think. Thanks!
>>>
>>> MSVC doesn't provide a non-trivial implementation of
>>> std::messages::do_open etc., so I don't see why it matters if libc++
>>> does not provide one on Windows.
>>>
>>
>> Hmm, glancing through libstdc++'s headers, it doesn't seem to do much more
>> :(. Then the question becomes (if the authors/copyright holders of the
>> support code in question do not want to have it used in win32 libc++),
>> should I just mimic current behavior of the other "Big 2" (MSVC/GCC) in this
>> regard? What would I be missing out on then? Is it really only n3290's
>> 22.4.7?
>>
>
> Implementing stubs was easy, so I just went ahead with it. I can always
> improve on it later if I want. Attached is another incremental patch.
>
> Notes:
>  - inclue/__bit_reference: Win32 <yvals.h> has a line: "#define _C2 1"
> which obviously messes up the templates in this file. I added n extra
> underscore to work around this, and did the same to _C1 for consistency.
>  - include/locale: include my support header for vasprintf, make the
> std::message functions stubs for Windows, mirroring other C++ Standard
> Library implementations on Windows.
>  - include/support/win32/support.h: add two missing functions and implement
> them naively in function of not-missing functions.
>  - src/locale.cpp: exclude langinfo.h inclusion for Windows. More work is
> needed here later to provide an alternative.
>  - src/support/win32/suppport.cpp: implementation.
>
> Please comment on this if something looks weird or wrong.
>
> Clang failed me (http://llvm.org/bugs/show_bug.cgi?id=10989) so, I'll need
> to resort to GCC and its unhelpful error messages in the meantime.
>
> Ruben
>

This time with patch. Note that the 32% is a rough estimate, mostly meant
for my own encouragement.

PS: thanks for the quick patching for the assembler error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110923/8f798ae2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32percent.patch
Type: application/octet-stream
Size: 8819 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110923/8f798ae2/attachment.obj>