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

[Eli Friedman]

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.

-Eli