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