<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 11:19 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 5 Nov 2013, at 18:19, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>

<br>
> IMO extern "C" is a clear indication that the user wants to interoperate between C and C++.  clang should have this warning on by default in extern "C" contexts.<br>
<br>
</div>The problem is that the compiler only sees the extern "C" when compiling in C++ mode, but the author of the header most likely compiles predominantly in C mode.<br></blockquote><div><br></div><div>Sure, but it'll help the end user to see a warning as soon as they compile in C++ mode, this seems like a big step up from runtime problems. I'm not sure how much the added complexity of a pragma, etc, would add over this.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It would be nice to have an annotation that could be added to a header that would let the compiler (or some tool) automatically check that it would work if compiled in either C or C++ mode.<br>
<br>
To check properly, you'd need to parse it as both C and C++ and do the full range of checks, ideally also checking that symbols have the same linkage in both versions.<br>
<br>
For a simple example of why this is difficult, in FreeBSD libc (and many other libc implementations) we have __BEGIN_DECLS and __END_DECLS macros.  These expand to extern "C" { and } respectively in C++ mode, or to nothing in C mode.  Just looking for extern "C", even inside an #ifdef, won't help you.<br>

<br>
I'd like to see such a tool, and ideally one that would let you specify what language dialects you expect a header to be valid for.  For example:<br>
<br>
#pragma clang valid_languages c99, c89, gnu99, gnu++99<br>
<br>
Although ideally something other than a pragma, so that we could have a __VALID_C and __VALID_CXX macros that would expand to something different depending on the compiler and the language dialects that we care about.<br>

<br>
The tool would then check trivial compatibility (does this file parse as valid code in all of these dialects), </blockquote><div><br></div><div>Might be a nice tool, sure - but it's still going to be an extra tool, I'd imagine, not just a flag passed to the compiler - at which point it's probably just as easy for someone to setup their build system with a few different configurations they want to ensure correctness for.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">but also less trivial properties, including:<br>
<br>
- Are all C structs declared in it POD types in C++?<br>
- Are all C functions extern "C" linkage in C++?<br>
- ...?<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>