__cxa_demangle

[Carlo Wood <carlo at alinoe dot com>]

On Thu, Dec 05, 2002 at 07:05:59PM -0600, Benjamin Kosnik wrote:
> >About the allocator template parameter, that is my original design.
> 
> I like the design you proposed below. How can I help you with this?
> Please let me know what I can do to help you. For instance, I could try
> to do the test infrastructure, but perhaps you have plans for that as
> well.

I'd be pleased if you would want to test it.

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.

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.

> >    template<typename Allocator>
> >      class session {
> >        private:
> >	  // ... lots of stuff here
> >        public:
> >	  explicit session(char const* in, int len);

Note: Input is read until a terminating 0 - OR until 'len' characters are read.
This would allow to do:

  f(std::string input)
  {
    session<my a_locator> s(input.data(), input.size());
    ...
  }

I hate copying strings ;)

> >	  static int decode_encoding(std::basic_string<char, std::char_traits<char>, Allocator>& output, char const* input, int len);

Idem

There is something that is unclear to me, perhaps you can clarify:

http://www.codesourcery.com/cxx-abi/abi.html#demangler says:

Behavior: The return value is a pointer to a null-terminated array of
characters, the demangled name.  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. 

What does this mean?
I'd guess it means that if you pass "i", then it should not give an
error but assume it is an extern "C" variable called "i".  However,
then how could you ever use __cxa_demangle to demangle a type?
And what about extern "C" variables that start with _Z ?

It seems most logical to me to treat "_Z..." always as a symbol, and
everything else as a type, and then when that *fails* to assume that
it was an extern "C" variable.  But that means you'd NEVER return
NULL.  The way I coded __cxa_demangle in the previous example was
to return NULL (error) when demangling of something with _Z fails, but
not otherwise.  That doesn't seem like what is meant in the quote above
however.

-- 
Carlo Wood <carlo@alinoe.com>