This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __cxa_demangle


>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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]