EEEEKS! The mangling changed!

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Dec  1, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Alexandre Oliva <aoliva@redhat.com> writes:
| > | On Nov 30, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > | 
| > | > Not everything in std:: gets resolved to __gnu_norm::.  You might want
| > | > to consult the documentation relating that work.  Things that are
| > | > really defined in std are still mangled as before.
| > | 
| > | This is a major issue.  When the Standard says something is defined in
| > | the ::std:: namespace, it has to be, otherwise template
| > | specializations won't work, because they have to be defined in the
| > | same namespace as the original template definition.
| 
| > Did you take a look at the documentation?
| 
| Just did.  Thanks for letting me know there was something to be read
| :-)
| 
| > Template specialization in
| > std:: just works as before.
| 
| Except that the mangled name is not what one would be entitled to
| expect.  

Oh, come on.  If you want to go the language lawyer route by citing the
C++ standard (as you did in your previous message), then I'm sure you
know that you're not founded to expect anything as far far as name
mangling goes.  As I said above, if you want to specialize a template in
std::, that just works.

| If the Standard says something is in namespace std, it had
| better be, and its name mangling should reflect that, otherwise we're
| defeating a major point of the multi-vendor C++ ABI.

the multi-vendor C++ ABI hardly specifies something beyond chapter 18
and language support.  

The multi-vendor C++ ABI was careful in not specifying how the
Standard library should be implemented.  An expectation that something
should be look like xxx is unfounded if not explicitly documented by
the implementation of the standard.

| Sure enough, templates most often have vague linkage anyway, but one
| can't dlopen a shared library containing a strong definition of a
| template specialization and use dlsym to obtain that specialization
| using the mangling that one could expect from the Standard definition,
| something is wrong.
| 
| Am I missing anything?

Yes.  Dlsym is fundamentally a C-oriented tool that is broken for C++
(I would say it is already broken for C, but that is a different issue).
Second, when you use that broken tool, you really want to be sure that
the string you use matches the documentation.  


There are much more important issues to worry about.  I'm much more
concerned about keeping users from breaking the ODR -- because that is
quite easy for any proposed aliasing scheme -- than about unfounded
expectations. 

-- Gaby