On Jan 1, 2011, at 3:38 PM, Sean Hunt wrote: > On 11-01-01 06:28 PM, Ted Kremenek wrote: >> Suppose FOO is defined by the including source file, or by *another header* >> that includes that header. Sometimes headers aren't fully self-contained; >> they are intended to be used in the context of other headers. One can argue >> whether that is good or bad practice, but it does happen. Thus context >> matters here as well; in this case, it can change what is actually valid >> source code defined by the header, and what isn't. >> >> Another example is a header that can be included by both an Objective-C or >> Objective-C++ source file. In one case it is Objective-C code, and in the >> other case it is Objective-C++ code. The difference can really matter in >> some cases. >> >> Ultimately, no source file, whether it is a header or a vanilla .c file, has >> any intrinsic semantics until is parsed, in the full proper context, by the >> compiler. That context includes all the -I and -D flags, etc. Since >> headers are inherently tied to the preprocessor, they can be used in all >> sorts of ways, and so ultimately their semantics are determined by the file >> that includes the header. That said, you can often skirt the issue with >> approximations, but if you are interested in replicating the semantics of a >> header that is seen by the actual developer in their project, headers need >> to be analyzed in the context of how they are actually used. > > Given that there is all this context sensitivity, why don't we obey the > caller when the caller tells us that a given file is C++, and instead go > "oh, it is .h, it must be C"?
Agreed, ignoring the -x option w.r.t. headers is possibly a bug in the driver. My point, however, was that even if that particular issue was fixed all the other larger issues with properly interpreting header files remains. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
