<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 4:33 PM, James Gregurich <span dir="ltr"><<a href="mailto:bayoubengal@mac.com" target="_blank">bayoubengal@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Aug 25, 2014, at 5:44 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>

><br>
> As was mentioned, this is *completely* off topic for the clang developers mailing list. Please discuss this somewhere else.<br>
<br>
</div>I don’t really get this.  So here you have people upset with a direction the project is taking….which IS “on topic.”</blockquote><div><br></div><div>FWIW, I don't think many people are at all upset. I think there are a couple of people upset on a mailing list, but none of them are significant contributors, and the contributors are quite happy with the direction.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> The direction of the project is determined by the existence of a particular problem…which is also apparently “on topic.”  And yet it is “off topic” to ask the very fundamental question: "What is the exact nature and scope of the problem?” How is that rational?<br>

<br>
How do you know how to address the problem if you don’t know what exactly what it is?<br></blockquote><div><br></div><div>You're assuming that your questions from the original email were highlighting the problem that Clang's Windows C++ compatibility is trying to solve. To repeat from the original email:</div>
<div><br></div><div>"""</div><div><span style="font-family:arial,sans-serif;font-size:13px">How many actual known instances of alleged broken lines are there in the entire Microsoft API header stack?</span><br style="font-family:arial,sans-serif;font-size:13px">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">If one had the dream of just fixing the headers, how big of a job would it actually be?</span><br></div><div>
<span style="font-family:arial,sans-serif;font-size:13px">"""</span></div><div><br></div><div>This is (IMO) not the relevant question for how or why we should be compatible. It doesn't matter how many lines there are or how big of a job fixing them would or wouldn't be. What folks are working on is being compatible with *existing* code on the Windows platform. The goal expressly isn't to change that code or fix those headers. So it doesn't really matter how big of a job it is to fix the headers.</div>
<div><br></div><div>Now, you could reasonably ask "why not try to fix the headers" and in fact that *did* come up when the project was first undertaken (many years ago) to start supporting Windows C++ code better. The simple answer was that in many cases the headers could not be changed. Additionally, in other cases the change wasn't always clearly a "fix" or not; it would be a matter that people disagree on with some preferring the code as-is. And that really wasn't an interesting debate to enter into because it is hard to argue that legacy code which works today should change to support some hypothetical future compiler.</div>
<div><br></div><div><br></div><div>When Clang originally started, it worked *very* hard to support non-standard C and C++ that was accepted by GCC because as the new compiler, compatibility was the key to adoption. This was essential to its success. We still did a cost/benefit tradeoff on supporting truly egregious constructs, but its pretty hard to argue that supporting the operating system's default system headers isn't worthwhile. We support *terrible* things to allow us to parse very old versions of glibc's public headers. We also have warnings to diagnose them and worked with the upstream maintainers to get some of these things fixed. But we still support the old headers because that's the key to adoption.</div>
<div><br></div><div><br></div><div>Now, what was off topic? The idea of going into some other operating system's header files and trying to make value judgements about what constitutes a "bad" line of code, and how many of them there are or how hard it would be to change them. It's mostly off topic because of the non-technical nature of the assessment: these lines of code are not broken or bad, they simply don't conform to C++ in the strictest sense. I suspect LLVM itself contains such header files. ;] It's also somewhat off topic because it is no longer relevant - we've already gone down the path of compatibility, and Clang is (at this point) essentially 99.99% compatible with the header files. If you want to work with Microsoft or any other operating system vendor to improve their header files, cool, but I think that discussion should be had primarily in those development communities unless there are technical questions about *why* one C++ construct is non-conforming.</div>
<div><br></div><div>And of course *all* of this is incredibly far afield from the actual subject of the thread on which it came up: switching the minimum supported *host* compiler from MSVC 2012 to MSVC 2013! This has zero bearing on how compatible Clang is with extensions used in system header files when *it* is the host compiler on a particular platform.</div>
</div></div></div>