tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Incorrect demangling



>> It looks as though anything that performs demangling should have
>> some way other than the symbol name of figuring out whether the
>> symbol came from C++, so that it is not tripped up by valid C
>> symbols that happen to mean something special when viewed as C++
>> symbols.
> It can't.

Sure it can.  There are at least two ways of doing it.

> Just look at the history of C++ and the way it has always been
> implemented.

"It's always been done this way, therefore it must always be done this
way"?  I sure hope that's not what you mean here, but it's what it
sounds like.  While I don't actually know, I also suspect that there's
more variety in existence than you credit.  A few very common
implementations != all implementations, in most cases.

> On most systems it is simply not possible to use non-C-compatible
> identifiers as result of the mangling, because the assembler or
> linker would reject them.

Even if true, this means "it can't be done using the legacy assembler
and linker", not "it can't be done".

I also suspect it's often not true.  Many, possibly even most,
assemblers and linkers allow dots in symbols; using .. instead of __
would completely fix the C-vs-mangled-C++ issue.  (So would extending
the symbol table entry with a bit somewhere that says "this is a
mangled C++ symbol", though that one requires changing more things that
deal with symbols.  Those are the two ways I mentioned above.)

> There is no bug here.

There most certainly is.  How fixable it is is a separate issue.

> Newer ld defaults to mangling off again.

Well, that'll just change the bug; now it'll report C++ symbols under
their mangled names.  (It'll bother me personally less, but that
doesn't mean it's fixed.)

> It is purely cosmetic anyway.

True.  So?  I don't think I ever called it anything else.

> If you want to use C and C++ in the same program, you either *depend*
> on being able to create functions that can be used from C++
> (including overloading etc)

Isn't that what `extern "C" { ... }' is for?  (I don't really know C++,
but I've seen enough to pick up on something like that.)

> or you will get a linker complain about redefinition on accidental
> matches.

That's another manifestation of the bug, though it's not one I ran into
personally.  I think I even mentioned it early in this thread.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index