<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>Also, could someone look at the enclosed patch for stdint.h?  This also fixes some failing tests, since VC++ doesn't have stdint.h.  Who is point on this?</div></blockquote><br>I'm not thrilled about using _M_IX86 and _M_X64 to detect what is really a library issue. I guess in the worst case we could have a configure-time check that determines whether we can #include_next <stdint.h>, but that's.... horrible.</div>

<div> </div>
<div>Unless someone has a better idea... ?</div></blockquote></div></blockquote></div>
<div><br>I used these symbols because they are implicitly defined to mimic VC++ in 32 and 64-bit mode respectively.  Would substituting a clang-specific implicit symbol be more acceptible, i.e. "_CLANG_MSVC"?</div>

<div> </div>
<div>Or, a stab in the dark, remove the #include, and internally switch the order of includes in the search path based on the Freestanding flag?  But I don't know the implications for the other headers Clang provides.</div>

<div> </div>
<div>Or, we disable the 7 tests that include stdint.h on Windows (once we have a mechanism that can do that).</div>
<div> </div>
<div>-John</div>
<div> </div>
<div>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com">John.Thompson.JTSoftware@gmail.com</a><br><br></div>