This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: __cxa_demangle
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Carlo Wood <carlo at alinoe dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Fri, 6 Dec 2002 12:20:30 -0600
- Subject: Re: __cxa_demangle
- References: <rt-6444-26525.13.5026931490963@rt.gnu.org><20021204232045.GA8085@alinoe.com><20021204183457.04334c27.bkoz@redhat.com><20021204185711.2c258cbd.bkoz@redhat.com><20021205014606.GA10993@alinoe.com><20021204224911.2c437a33.bkoz@redhat.com><20021205142313.GB12736@alinoe.com><20021205190559.62a6193b.bkoz@redhat.com><20021206022323.GA7552@alinoe.com>
>I'd be pleased if you would want to test it.
Great. I'll work on this.
>I think that the namespace demangler {} and the struct demangle (in __gnu_cxx?)
>should be in a seperate header file that is not normally included by users.
>This header file then can be included in the source file that will define
>and export __cxa_demangle(). That will then normally not drag in the templates
>for normal compilation.
Sounds like a good plan.
>I'll write this header file, and the implementation of __cxa_demangle, and
>send it to you. If you'd be so kind to then check the license/header stuff
>for me - add out-of-memory exception handling (I *never* coded execptions yet,
>so I definitely need help with that) - to test it, and to merge the source
>file and header into the libstdc++ then around that time I suppose I can cough
>up the needed documentation as well, if you tell me where/how.
Sounds great. Most of the documentation is written in HTML. I suspect
this stuff will go in chapter 18, support. You can see the current docs here:
http://gcc.gnu.org/onlinedocs/libstdc++/18_support/howto.html#5
Not too extensive at the moment, I'm afraid.
> Ambiguities are possible between extern
>"C" object names and internal built-in type names, e.g. "i" may be either
>an object named "i" or the built-in "int" type. Such ambiguities should
>be resolved to user names over built-in names.
extern "C"
{
struct i
{
int j;
};
i obj;
}
void foo(i my, char* c) { }
void foo(int m, char* c) { }
00000000 T _Z3foo1iPc
00000006 T _Z3fooiPc
Maybe I don't understand the ambiguity? These are distinct. For
non-function arguments, the extern "C" structs won't be mangled, so
there is no need to demangle.
A C object that is unfortunately named "i" would be mangled as
i
without the preceeding _Z, so it wouldn't need to be demangled (see
below). I'm assuming you are talking about this as a function argument,
right? Can't you just check for an int before the "i"?
ie:
#if 0
class i
{
public:
i();
};
i::i(){};
#else
extern "C"
{
struct obj
{
int j;
};
obj i;
}
#endif
i();
};
i::i(){};
ie:
00000006 T _ZN1iC1Ev
vs.
00000000 B i
>And what about extern "C" variables that start with _Z ?
Wouldn't this be a reserved name for implementors? Obviously, in this
case, C++ demangling would be impossible/undefined.
-benjamin