<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 2, 2014 at 1:43 PM, Seth Cantrell <span dir="ltr"><<a href="mailto:seth.cantrell@gmail.com" target="_blank">seth.cantrell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="h5"><div>On Oct 2, 2014, at 1:39 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 2, 2014 at 7:21 AM, Seth Cantrell <span dir="ltr"><<a href="mailto:seth.cantrell@gmail.com" target="_blank">seth.cantrell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><div>On Oct 2, 2014, at 1:12 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br></span><blockquote type="cite"><div style="font-family:Menlo-Regular;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Oct 1, 2014 at 7:54 PM, Seth Cantrell<span> </span><span dir="ltr"><<a href="mailto:seth.cantrell@gmail.com" target="_blank">seth.cantrell@gmail.com</a>></span><span> </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">With C++ modules being far enough along to be included in -fmodules now I tried enabling -fmodules on a small C++ program I have laying around. I was impressed that it almost all worked right away.<br><br>Here's the issue I ran into with one header:<br><br><br>glcorearb.h:616:1: error: import of C++ module 'Darwin.C.stddef' appears within extern "C" language linkage specification<br>#include <stddef.h><br>^<br>glcorearb.h:5:1: note: extern "C" language linkage specification begins here<br>extern "C" {<br>^<br>glcorearb.h:1517:1: error: import of C++ module 'Darwin.C.inttypes' appears within extern "C" language linkage specification<br>#include <inttypes.h><br>^<br>glcorearb.h:5:1: note: extern "C" language linkage specification begins here<br>extern "C" {<br>^<br><br><br>Even without modules it seems like people should be taking care not #include a header in a context that may not be compatible with the content of those headers. Here we are building C++ and stddef.h and inttypes.h are therefore C++ headers that might not work in an extern "C" context. Platforms owners, who are in control of both the including file and the included file can legitimately do this, but I don't think this is good practice when included someone else's header. However the standards don't clearly disallow this</blockquote><div><br></div><div>C++ absolutely does disallow it for its own headers (which include <stddef.h> and <inttypes.h>):</div><div><br></div></span><div>[using.headers]p3: "A translation unit shall include a header only outside of any external declaration or definition, and shall include the header lexically before the first reference in that translation unit to any of the entities declared in that header. No diagnostic is required.”</div></div></div></div></div></blockquote><div><br></div>Oh, excellent. That means I can report it to the header’s devs as a bug with a nice standards quote. Thanks.</div><span><div><br></div><div><br><blockquote type="cite"><div style="font-family:Menlo-Regular;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></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">and I have certainly seen circumstances where people recommended extern "C" { #include <system header> } for various reasons.<br><br>In this specific case it's not even deliberate as far as I can tell, but it's worked and so no one's bothered to fix it here. A quick hack to remove these #includes from extern "C" solved the issue for me.<br><br>Anyway, I checked<span> </span><a href="http://clang.llvm.org/docs/Modules.html#modularizing-a-platform" target="_blank">http://clang.llvm.org/docs/Modules.html#modularizing-a-platform</a><span> </span>but didn't notice any recommendations that apply here. So what should be recommended? Is this an 'anti-pattern' for modules? An anti-pattern for 'well organized' non-module headers? Should modules be able to coexist with these kinds of shenanigans when the code worked fine pre-modules? Should I contact the developers of this header and recommend a change? (It's an automatically generated header from gl3w.)</blockquote><div><br></div><div>See<span> </span><a href="http://clang.llvm.org/docs/Modules.html#module-declaration" target="_blank">http://clang.llvm.org/docs/Modules.html#module-declaration</a><span> </span>and in particular the description of the [extern_c] attribute. By default, a module that can be used in C++ can only be used at global scope (outside of all namespaces and language linkage specifications). This attribute says that the module provides a C interface to C++ code, and thus:</div><div>1) The module is built surrounded by an implicit extern "C" context, and</div><div>2) The module can be imported within a top-level extern "C" linkage specification.</div><div><br></div><div>This attribute should typically be applied to modules whose headers contain the</div><div><br></div><div>#ifdef __cplusplus</div><div>extern "C" {</div><div>#endif</div><div>// ...</div><div>#ifdef __cplusplus</div><div>}</div><div>#endif</div><div><br></div><div>pattern. Depending on your platform, it may or may not make sense to use the [extern_c] on your libc module; Darwin's doesn't (probably because its module map predates this attribute) but my glibc module map does.</div></div></div></div></div></blockquote></div><br></span><div>Would it make sense for the compiler, in the interest of backwards compatibility, to just go ahead and import a module ignoring the fact that it’s imported in an extern “C” context?</div></div></blockquote><div><br></div><div>That breaks things. Suppose you have a C header that does *not* include the above conditional 'extern "C" {' shenanigans. From C++ code, you'd use that library like this:</div><div><br></div><div>extern "C" {</div><div>  #include "that_library.h"</div><div>}</div><div><br></div><div>If you supply a module map for that library and you add neither 'requires !cplusplus' nor '[extern_c]', *and* we follow your suggestion, then we'd build that_library.h has a non-extern-C C++ header file, which will lead to weird link errors.</div></div></div></div></div></blockquote><div><br></div></div></div><div>Doesn't providing such a module map constitute an incorrect assertion that the header works as a C++ module, and so an error there would be okay?</div></div></blockquote><div><br></div><div>An error is OK, so long as it's easy to diagnose and understand. We can do a lot better if we catch this during compilation than during linking (or worse, during dynamic linking or at dlopen time).</div><div><br></div><div>If a module had to list its supported languages somehow, I think that would be a completely reasonable position. As it stands, we have an opt-out system, not an opt-in one; a module would need to say "requires !cplusplus, !cuda, !objc, !opencl, ..." to explicitly opt out of all the language modes where it doesn't work or hasn't been tested. C++ is arguably a special case here (because it introduces an ABI difference by default), but I still don't think it's reasonable to expect every C module author to write "requires !cplusplus"; the current rule prompts them to write [extern_c] in those cases where it's necessary to do so.</div><div><br></div><div>That said, I think we should extend the diagnostic to point out that the error can be resolved by adding [extern_c] to the module map.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I think a more common situation will be people just flipping on -fmodules without providing module maps for all their headers, so for them extern "C" { #include "that_library.h" } will work just fine. And if they do get around to writing their own module maps they should correctly mark C modules as C.</div></div></blockquote><div><br></div><div>I think the error has a lot of value in this situation: if they forget to mark their modules as C, it stops the build from accidentally generating wrong code. (And [extern_c] is the way to mark a module as C-but-usable-from-C++.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Of course if my system's module map used the extern_c attribute there'd be no problem either way, so I agree that's the real solution. I'll file a bug with Apple for this as well.</div><div><br></div><div>And here's the bug I filed with Khronos for their header: <a href="https://www.khronos.org/bugzilla/show_bug.cgi?id=1236" target="_blank">https://www.khronos.org/bugzilla/show_bug.cgi?id=1236</a></div></div></blockquote><div><br></div><div>Thank you for filing both of those bugs! </div></div></div></div>