<p dir="ltr">Windows version of clang-format.</p>
<div class="gmail_quote">On Sep 3, 2013 6:00 PM, "Jordan Rose" <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  > As for the motivation, it's that Windows doesn't properly support outputting UTF-8-encoded text to the console using narrow character C library functions (and iostream), as it's usually done in Linux, OS X and other modern Unix-like systems (more details, e.g. here: <a href="http://alfps.wordpress.com/2011/11/22/unicode-part-1-windows-console-io-approaches/" target="_blank">http://alfps.wordpress.com/2011/11/22/unicode-part-1-windows-console-io-approaches/</a>). So we need to keep old implementation that disallows non-ascii characters, until someone figures out the right strategy for handling Unicode in Windows version of Clang/LLVM.<br>

<br>
  Right, that I understand. What I meant was, why does Windows need access to the full Unicode implementation? Just for the unit tests? Or do you have another use case in mind?<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D1559" target="_blank">http://llvm-reviews.chandlerc.com/D1559</a><br>
</blockquote></div>