<div class="gmail_quote">2011/9/22 Ruben Van Boxem <span dir="ltr"><<a href="mailto:vanboxem.ruben@gmail.com">vanboxem.ruben@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">2011/9/22 Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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