<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; "><div><div>On Feb 14, 2013, at 2:47 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><blockquote type="cite">On Thu, Feb 14, 2013 at 1:58 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> I understand what you're trying to do here, because indeed the standard<br>
> says that language linkage only applies to functions and variables with<br>
> external linkage, but I think the right thing to do is to just acknowledge<br>
> that we (AFAIK, like gcc) just give C language linkage to everything<br>
> declared in extern "C" and be done with it. There are much more<br>
> significant ways in which we deviate from the standard's definition of<br>
> language linkage.<br>
<br>
</div>That was one of the listed options, and while some callers do want the<br>
notion of "usable from C", they should be easy to update (mostly going<br>
from foo.isExternC() to foo.isExternC() &&<br>
!isExternalLinkage(foo.getLinkage()).<br>
<br>
I don't have a big preference on this, but Richard suggested on IRC<br>
going the other way: fixing llvm's assumptions about name mangling and<br>
reverting this patch.<br></blockquote><div><br></div><div>Regardless of what we do with this patch, we should fix LLVM's name mangling assumptions, since they are not portable: EDG for instance will "miscompile" the code, since it correctly implements the language linkage rules per the standard (even in its GCC-compatible mode), and consequently mangles static functions inside extern "C".</div></div></blockquote><div><br></div>Ah, that's interesting.</div><div> </div><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What are the other deviations from language linkage that you know?</blockquote><div><br></div><div>We don't correctly enforce the "all C language linkage declarations with the same name declare the same entity" rule, particularly within namespaces. We accept this, for instance:</div>
<div><br></div><div>namespace N { extern "C" void f(); } extern "C" int f();</div><div><br></div><div>However, this is pretty obviously a bug.</div></div></blockquote><div><br></div><div>Yeah, most of our redeclaration checking is pretty specific to obvious</div><div>in-scope redeclaration; we're also got a number of bugs about matching</div><div>up local-extern declarations.</div><br><blockquote type="cite"><div class="gmail_quote"><div> </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; position: static; z-index: auto; ">
The<br>
one I know in that we don't include it in function types. Do you know<br>
the rationale for it being what it is on the standard? If we implement<br>
what it looks like gcc implements (all variables and functions have<br>
language linkage), do you think a DR would be reasonable?<br></blockquote><div><br></div><div>I do not want for us to remain non-conforming in perpetuity, unless we have a *really* good reason to do so -- we should either fix our implementation or fix the standard.</div>
</div>
</blockquote></div><br><div>I agree.</div><div><br></div><div>John.</div></body></html>