Re: PATCH: Fix linkage in libsupc++

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark@codesourcery.com> writes:

| With the new symbol visibility patches, we have to be careful not to
| get incorrect linkage in the libraries; if the default visibility is
| not "default" when we include the headers, things get confused.
| Things are even worse for ports that use "hidden" visibility by
| default; the ARM/Symbian OS port will be one such.
| 
| A tricky problem here was that this pattern was present in a lot of
| the libsupc++ files:
| 
|   // cxxabi.h
| 
|   namespace __cxxabiv1 { 
|      extern "C" void f();
|   }
| 
|   // f.c
| 
|   #include <cxxabi.h>
|   
|   extern "C" void f() {}
| 
| This is *not* a definition of the function declared in the header;
| it's just an overloaded function.  You must write "__cxxabiv1::f" or
| put the definition inside the namespace.

If the "visibility" patch does something like that, then the
visibility patch is doing something very very *odd*.
An overload set cannot contain two different functions
with a C language linkage.  We don't have overloads in C.
If the above code is accepted, then what appears at the global scope
above is a definition for the "f" at __cxxabiv1 scope. 

7.5/6
  At most one function with a particular name can have C language
  linkage. Two declarations for a function with C language linkage
  with the same function name (ignoring the namespace names that
  qualify it) that appear in different namespace scopes refer to the
  same function. Two declarations for an object with C language
  linkage with the same name (ignoring the namespace names that
  qualify it) that appear in different namespace scopes refer to the
  same object. [Note: because of the one definition rule (3.2), only
  one definition for a function or object with C linkage may appear in
  the program; that is, such a function or object must not be defined
  in more than one namespace scope. For example, 
 
     namespace A {
       extern "C" int f();
       extern "C" int g() { return 1; }
       extern "C" int h();
     }

     namespace B {
       extern "C" int f();              // A::f and B::f refer
                                        // to the same function
       extern "C" int g() { return 1; } // ill-formed, the function g
                                        // with C language linkage
                                        // has two definitions
     }

     int A::f() { return 98; }          // definition for the function f
                                        // with C language linkage
     extern "C" int h() { return 97; }
                                        // definition for the function h
                                        // with C language linkage
                                        // A::h and ::h refer to the same function
   
   --end note]


| I did not attempt to fix all of the V3 headers; I'm only concerned
| with libsupc++ at the moment.  However, similar changes should
| probably be made throughout V3.  Otherwise, linkage will be wrong if
| people #include (say) <iostream> with a non-default symbol visibility.

I'm not convinced by your example and the rationale you gave.  What am
I missing?  Most certainly, in your example ::f and __cxxabiv1::f
refer to the same function and we should have &::f == &__cxxabiv1::f.

I agree with your patch explicitly seeting the visibility, but I do
not agree with the overload bits.

-- Gaby