[cfe-dev] clang trunk: extern "C"/static problem

[Richard Smith]

On Fri, Mar 15, 2013 at 3:13 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > The committee has already reaffirmed this once (albeit quite a long time
> > ago).
> >
> > Having just discussed this at length with fellow CWG member James
> Dennett,
> > we think (hopefully James will correct me if I'm misstating something):
> >
> >  * Relying on the names of internal-linkage symbols does not seem
> > particularly reasonable,
> >  * The status quo (Clang rejecting the code in question) also seems far
> from
> > ideal,
> >  * We are about an order of magnitude below having enough evidence to
> > justify a change to the standard,
> >  * It's not reasonable for Clang to be permanently non-conforming here.
> >
> > Based on the above, I'd like to suggest a solution: we teach
> CodeGenModule
> > to keep track of the internal-linkage functions and variables which are
> > declared within C language linkage blocks, and when we reach the end of
> the
> > module, for each such name, if (1) we saw exactly one function or
> variable
> > with that name, and (2) that name is not yet defined in the module, we
> emit
> > an internal linkage alias mapping the "expected" name to the mangled
> name.
> >
> > This should be a pretty minimal and non-invasive change, and allows us to
> > both conform and accept the code in question. Does that seem OK to
> everyone?
>
> I think I am ok with it. One problem with going this way is that we
> don't have any semantic checking for the "sudo language linkage" going
> on, so it is not very clear what "declare within C language blocks"
> means. For example, should this 'f' be on the list to get an alias?
>

I'm fine with requiring the definition to be lexically within an extern "C"
block; I view this as being entirely a quality-of-implementation issue,
though, so doing better than that would also work for me.


> static void f();
> extern "C" {
>   void f();
> }
> void f() {
> }
> void use() {
>   f();
> }
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130315/7000f2e8/attachment.html>