
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 1, 2013, at 2:45 , Jyoti <<a href="mailto:jyoti.yalamanchili@gmail.com">jyoti.yalamanchili@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Jordan,</div><div>I understand it's overall purpose now. However, need some more clarity. So does this mean that if system-header-simulator.h is included </div><div>in a test file all system function declarations in system headers will be overridden by those in system-header-simulator.h ?</div></blockquote><div><br></div><div>No, no. The philosophy behind the Clang regression tests is that <i>none</i> of them should include system headers*, so that we don't depend on the user's build environment to run the test suite. #include-ing system-header-simulator.h is just like #include-ing any other header in that it doesn't <i>replace</i> anything, but in this case we didn't include any of the system headers anyway.</div><div><br></div><div>* The one exception to this rule is the compiler-specific headers that are shipped alongside clang itself, which some people would consider to be "system headers" (and which have the same behavior changes as actual headers from your system).</div><div><br></div><br><blockquote type="cite">

<div>In effect, i want to know what #pragma clang system_header" means or what it does? </div></blockquote><div><blockquote type="cite">I know #pragma clang is a directive to clang and it is informing something about system headers to clang but precisely what is my question.</blockquote><div><br></div></div><div>Basically, it means "pretend this file came from /usr/include (or wherever MSVC stores the headers for Windows) so that we get the same behavior tweaks". I can't think of any real-world uses off the top of my head, but it's very useful for testing.</div><div><br></div><br><blockquote type="cite"><div>Does it also mean that it should be possible to compile a test file invoking system functions by just including system-header-simulator.h </div><div>file and not including the system headers directly ? </div><div>I did try by including malloc in test file div-zero.cpp and including system-header-simulator.h instead of stdlib.h, but fails to compile.</div></blockquote><div><br></div><div>In C (and C++, and Objective-C), headers just tell you what functions and types are present. If you declare them yourself (in a header file, in your main source file, or in a fake system header like system-header-simulator.h), you can write code that uses them, and it will "compile". However, the real definitions of system functions live in the system DLLs (or in a statically-linked system library), and so if you get the names wrong in your declarations then your program will fail to link, and if you get the names right but the types wrong your program will crash at runtime.</div><div><br></div><div>This has nothing to do with system headers or not system headers; it's just how C works.</div><div><br></div><div><br></div><div>If you're still confused, replace the word "system" in the pragma with "lenient-but-sane", which is a rough description of how we treat system headers. We don't warn about things as much, because we know the user won't want to modify this header (the "lenient" bit), but we also assume that the code is probably doing the right thing, because it's production code that's running every day and is presumably well-tested (the "sane" bit). (For example, in the analyzer specifically, we assume functions like fopen() will be sane and not free the C string you pass to it.) By default, we assume all headers that come from certain locations like /usr/include ("system headers") are "sane" and we should be "lenient" about diagnosing issues within them.</div><div><br></div></div>Jordan</body></html>