[c++] Another question about demangler output

[c++] Another question about demangler output

[Daniel Jacobowitz]

Consider this program:
template<typename B> class BB { public: BB() { }
 typedef int (*foot)(void);
 operator foot () { return 0; }
};

BB<int> obj;

int foo()
{
  return ((int (*)(void)) obj) != 0;
}

One symbol generated by this program is _ZN2BBIiEcvPFivEEv, which demangles
as:
  BB<int>::operator int (*)()()

But that output is quite annoying for me, because it's nothing like legal
C++, as far as I have been able to tell.  But I can't find a way to express
that type without using an intermediate typedef.

The reason this bugs me is that I've been writing a fairly dumb "parser" for
things which can appear in symbol names, with the goal of creating a
canonical form for such names for GDB's use.  The problem is in some ways
easier and in some ways harder than parsing C++; we don't need to
differentiate between various possible meanings for identifiers, but at the
same time we _can't_ differentiate between them.  I've found no reasonable
way for it to figure out what "A::operator int (*)()()" means.

Am I right that this can't be expressed in C++ without using an intermediate
type?  If I am right, I'm not sure what to do.  If I'm wrong, we can correct
the demangler.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [c++] Another question about demangler output

[Ian Lance Taylor]

Daniel Jacobowitz <drow@mvista.com> writes:

> Consider this program:
> template<typename B> class BB { public: BB() { }
>  typedef int (*foot)(void);
>  operator foot () { return 0; }
> };
> 
> BB<int> obj;
> 
> int foo()
> {
>   return ((int (*)(void)) obj) != 0;
> }
> 
> One symbol generated by this program is _ZN2BBIiEcvPFivEEv, which demangles
> as:
>   BB<int>::operator int (*)()()

You don't need the template, of course.  You can get your irritating
result with simply

class BB { typedef int (*foot)(void); operator foot (); };
BB::operator foot() { return 0; }

This gives _ZN2BBcvPFivEEv which (currently) demangles as
    BB::operator int (*)()()

But using a gcc extension, I can do this without a typedef:

class BB { operator typeof (int(*)())(); };
BB::operator typeof (int(*)())() { return 0; }

So this suggests that the demangler should be changed.  When a
conversion operator is used with a complex type, the demangler should
demangle the name using `typeof'.

Ian

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Daniel Jacobowitz <drow@mvista.com> writes:

| One symbol generated by this program is _ZN2BBIiEcvPFivEEv, which demangles
| as:
|   BB<int>::operator int (*)()()
| 
| But that output is quite annoying for me, because it's nothing like legal
| C++, as far as I have been able to tell.

Yep, that is not valid C++.

[...]

| same time we _can't_ differentiate between them.  I've found no reasonable
| way for it to figure out what "A::operator int (*)()()" means.

It is not C++.  You have to go  through a type-alias indirection.

| Am I right that this can't be expressed in C++ without using an intermediate
| type?  If I am right, I'm not sure what to do.  If I'm wrong, we can correct
| the demangler.

I think the ABI rules for mangling and demangling is too
schizophrenic.  At one point, it is token-oriented and at another
point it is not.  Another level of difficulty is that typedef-name have
no linkage.  Did they have internal/external, I would say just go with
the intermediate type-alias name; but you can't :-(

-- Gaby

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Ian Lance Taylor <ian@wasabisystems.com> writes:

[...]

| This gives _ZN2BBcvPFivEEv which (currently) demangles as
|     BB::operator int (*)()()
| 
| But using a gcc extension, I can do this without a typedef:
| 
| class BB { operator typeof (int(*)())(); };
| BB::operator typeof (int(*)())() { return 0; }

If you do that, then you might end up accpeting two different
declarations as same where the token-oriented scheme (ODR) would have
kept them separate.  That is, you would not be able to differentiate

tu1.C:

  struct B { operator typeof(int(*)())(); };

from

tu2.C:

  struct B { typedef int (*foo)(); operator foo(); };

ODR says they are different.

-- Gaby

Re: [c++] Another question about demangler output

[Ian Lance Taylor]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Ian Lance Taylor <ian@wasabisystems.com> writes:
> 
> [...]
> 
> | This gives _ZN2BBcvPFivEEv which (currently) demangles as
> |     BB::operator int (*)()()
> | 
> | But using a gcc extension, I can do this without a typedef:
> | 
> | class BB { operator typeof (int(*)())(); };
> | BB::operator typeof (int(*)())() { return 0; }
> 
> If you do that, then you might end up accpeting two different
> declarations as same where the token-oriented scheme (ODR) would have
> kept them separate.  That is, you would not be able to differentiate
> 
> tu1.C:
> 
>   struct B { operator typeof(int(*)())(); };
> 
> from
> 
> tu2.C:
> 
>   struct B { typedef int (*foo)(); operator foo(); };
> 
> ODR says they are different.

I don't know who the ``you'' is in ``if you do that.''  Or else I
don't know what the ``that'' is.

I gave two code samples, and g++ uses the same name mangling for both.
Try it.  Is that a bug in g++?

Frankly, I don't see how g++ could do anything else.

If g++ did mangle the names differently, then the demangler would be
able to produce different demanglings for them.  Since g++ mangles the
names identically, the demangler must obviously produce the same
demangling for them.  I'm proposing that the demangler use the
`typeof' demangling, instead of the ambiguous demangling in which the
typedef has disappeared.

Note that you don't need to use typeof to get identical manglings for
names which you seem to be arguing must be mangled differently.  Just
compare
    class BB { typedef int I; operator I(); };
and
    class BB { operator int(); };

Ian

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Ian Lance Taylor <ian@wasabisystems.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Ian Lance Taylor <ian@wasabisystems.com> writes:
| > 
| > [...]
| > 
| > | This gives _ZN2BBcvPFivEEv which (currently) demangles as
| > |     BB::operator int (*)()()
| > | 
| > | But using a gcc extension, I can do this without a typedef:
| > | 
| > | class BB { operator typeof (int(*)())(); };
| > | BB::operator typeof (int(*)())() { return 0; }
| > 
| > If you do that, then you might end up accpeting two different
| > declarations as same where the token-oriented scheme (ODR) would have
| > kept them separate.  That is, you would not be able to differentiate
| > 
| > tu1.C:
| > 
| >   struct B { operator typeof(int(*)())(); };
| > 
| > from
| > 
| > tu2.C:
| > 
| >   struct B { typedef int (*foo)(); operator foo(); };
| > 
| > ODR says they are different.
| 
| I don't know who the ``you'' is in ``if you do that.''  Or else I
| don't know what the ``that'' is.
| 
| I gave two code samples, and g++ uses the same name mangling for both.
| Try it.  Is that a bug in g++?
| 
| Frankly, I don't see how g++ could do anything else.

The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
function declaration should be mangled differently from any standard
C++ construction.  After all, the ABI has provided hook for vendor
extension. 

-- Gaby

Re: [c++] Another question about demangler output

[Daniel Jacobowitz]

On Sat, Dec 06, 2003 at 09:08:49PM -0500, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > Consider this program:
> > template<typename B> class BB { public: BB() { }
> >  typedef int (*foot)(void);
> >  operator foot () { return 0; }
> > };
> > 
> > BB<int> obj;
> > 
> > int foo()
> > {
> >   return ((int (*)(void)) obj) != 0;
> > }
> > 
> > One symbol generated by this program is _ZN2BBIiEcvPFivEEv, which demangles
> > as:
> >   BB<int>::operator int (*)()()
> 
> You don't need the template, of course.  You can get your irritating
> result with simply
> 
> class BB { typedef int (*foot)(void); operator foot (); };
> BB::operator foot() { return 0; }
> 
> This gives _ZN2BBcvPFivEEv which (currently) demangles as
>     BB::operator int (*)()()
> 
> But using a gcc extension, I can do this without a typedef:
> 
> class BB { operator typeof (int(*)())(); };
> BB::operator typeof (int(*)())() { return 0; }
> 
> So this suggests that the demangler should be changed.  When a
> conversion operator is used with a complex type, the demangler should
> demangle the name using `typeof'.

I'm OK with this.  It will require some change in GDB, because a
simplistic approach to parsing can handle the existing output (member
function?  named "operator " followed by a string that isn't an
operator name?  Must be a cast to STRING!).  But GDB and other
consumers can be fixed, and typeof resolves the ambiguity for my
purposes quite nicely.

It is my goal for this program to be idempotent on the output of the v3
demangler, i.e. to be able to build a parse tree that the demangler's
print functions will produce the input string from.  So far I'm fairly
close.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [c++] Another question about demangler output

[Daniel Jacobowitz]

On Sun, Dec 07, 2003 at 05:24:46AM +0100, Gabriel Dos Reis wrote:
> Ian Lance Taylor <ian@wasabisystems.com> writes:
> 
> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> | 
> | > Ian Lance Taylor <ian@wasabisystems.com> writes:
> | > 
> | > [...]
> | > 
> | > | This gives _ZN2BBcvPFivEEv which (currently) demangles as
> | > |     BB::operator int (*)()()
> | > | 
> | > | But using a gcc extension, I can do this without a typedef:
> | > | 
> | > | class BB { operator typeof (int(*)())(); };
> | > | BB::operator typeof (int(*)())() { return 0; }
> | > 
> | > If you do that, then you might end up accpeting two different
> | > declarations as same where the token-oriented scheme (ODR) would have
> | > kept them separate.  That is, you would not be able to differentiate
> | > 
> | > tu1.C:
> | > 
> | >   struct B { operator typeof(int(*)())(); };
> | > 
> | > from
> | > 
> | > tu2.C:
> | > 
> | >   struct B { typedef int (*foo)(); operator foo(); };
> | > 
> | > ODR says they are different.
> | 
> | I don't know who the ``you'' is in ``if you do that.''  Or else I
> | don't know what the ``that'' is.
> | 
> | I gave two code samples, and g++ uses the same name mangling for both.
> | Try it.  Is that a bug in g++?
> | 
> | Frankly, I don't see how g++ could do anything else.
> 
> The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
> function declaration should be mangled differently from any standard
> C++ construction.  After all, the ABI has provided hook for vendor
> extension. 

I can't see why in this case.  It's still a conversion operator to "int
(*) ()", right?  The ABI defines the mangled name of this operator.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Daniel Jacobowitz <drow@mvista.com> writes:

| On Sun, Dec 07, 2003 at 05:24:46AM +0100, Gabriel Dos Reis wrote:
| > Ian Lance Taylor <ian@wasabisystems.com> writes:
| > 
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > | 
| > | > Ian Lance Taylor <ian@wasabisystems.com> writes:
| > | > 
| > | > [...]
| > | > 
| > | > | This gives _ZN2BBcvPFivEEv which (currently) demangles as
| > | > |     BB::operator int (*)()()
| > | > | 
| > | > | But using a gcc extension, I can do this without a typedef:
| > | > | 
| > | > | class BB { operator typeof (int(*)())(); };
| > | > | BB::operator typeof (int(*)())() { return 0; }
| > | > 
| > | > If you do that, then you might end up accpeting two different
| > | > declarations as same where the token-oriented scheme (ODR) would have
| > | > kept them separate.  That is, you would not be able to differentiate
| > | > 
| > | > tu1.C:
| > | > 
| > | >   struct B { operator typeof(int(*)())(); };
| > | > 
| > | > from
| > | > 
| > | > tu2.C:
| > | > 
| > | >   struct B { typedef int (*foo)(); operator foo(); };
| > | > 
| > | > ODR says they are different.
| > | 
| > | I don't know who the ``you'' is in ``if you do that.''  Or else I
| > | don't know what the ``that'' is.
| > | 
| > | I gave two code samples, and g++ uses the same name mangling for both.
| > | Try it.  Is that a bug in g++?
| > | 
| > | Frankly, I don't see how g++ could do anything else.
| > 
| > The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
| > function declaration should be mangled differently from any standard
| > C++ construction.  After all, the ABI has provided hook for vendor
| > extension. 
| 
| I can't see why in this case. 

the demangler is introducing a vendor-specific operator where there
weren't. 

-- Gaby

Re: [c++] Another question about demangler output

[Ian Lance Taylor]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
> function declaration should be mangled differently from any standard
> C++ construction.  After all, the ABI has provided hook for vendor
> extension. 

So you are arguing that this is a bug in g++.

I don't agree.  To me it seems natural that typeof should simply be
replaced by the resulting type when doing name mangling.  I don't see
why that is any different from the way that a typedef is simply
replaced by the resulting type.  The GNU typeof extension is really
just an anonymous typedef.  I see no reason to treat it differently
for name mangling purposes.

If somebody wants to change g++, then I guess any type defined by
typeof should be replaced by something like
    u LEN typeof_XXX
where LEN is the length of the following string and XXX is the mangled
form of the expression which is the argument to typeof.

Ian

Re: [c++] Another question about demangler output

[Ian Lance Taylor]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> the demangler is introducing a vendor-specific operator where there
> weren't. 

Well, do you have a better suggestion for how to demangle
    _ZN2BBcvPFivEEv
?

Ian

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Ian Lance Taylor <ian@wasabisystems.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
| > function declaration should be mangled differently from any standard
| > C++ construction.  After all, the ABI has provided hook for vendor
| > extension. 
| 
| So you are arguing that this is a bug in g++.

Yes.

| I don't agree.  To me it seems natural that typeof should simply be
| replaced by the resulting type when doing name mangling.

Elsewhere, we seem to refrain from "folding".  Which is what I
referred to in an earlier message as a schizophrenic position.

-- Gaby

Re: [c++] Another question about demangler output

[Ian Lance Taylor]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Ian Lance Taylor <ian@wasabisystems.com> writes:
> 
> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> | 
> | > The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
> | > function declaration should be mangled differently from any standard
> | > C++ construction.  After all, the ABI has provided hook for vendor
> | > extension. 
> | 
> | So you are arguing that this is a bug in g++.
> 
> Yes.
> 
> | I don't agree.  To me it seems natural that typeof should simply be
> | replaced by the resulting type when doing name mangling.
> 
> Elsewhere, we seem to refrain from "folding".  Which is what I
> referred to in an earlier message as a schizophrenic position.

g++ refrains from folding in expressions which appear as template
arguments.  I don't know whether that is right or wrong.

However, this case is not in a template argument, so I don't think
that arguments about folding apply here.

In any case, I am hardly a C++ expert.  If anybody has a better
suggestion for how to demangle _ZN2BBcvPFivEEv, I'm happy to hear it.

Ian

Re: [c++] Another question about demangler output

[Daniel Jacobowitz]

On Sat, Dec 06, 2003 at 11:46:30PM -0500, Ian Lance Taylor wrote:
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> 
> > Ian Lance Taylor <ian@wasabisystems.com> writes:
> > 
> > | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> > | 
> > | > The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
> > | > function declaration should be mangled differently from any standard
> > | > C++ construction.  After all, the ABI has provided hook for vendor
> > | > extension. 
> > | 
> > | So you are arguing that this is a bug in g++.
> > 
> > Yes.
> > 
> > | I don't agree.  To me it seems natural that typeof should simply be
> > | replaced by the resulting type when doing name mangling.
> > 
> > Elsewhere, we seem to refrain from "folding".  Which is what I
> > referred to in an earlier message as a schizophrenic position.
> 
> g++ refrains from folding in expressions which appear as template
> arguments.  I don't know whether that is right or wrong.

Personally, I think it's wrong.  In fact, I think it's ludicrously
inconsistent, after the last week of trying to deal with it.  But I
know very little about C++, so I assume there was some reason for doing
it this way.  If someone has a pointer to the discussion/explanation....

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Ian Lance Taylor <ian@wasabisystems.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Ian Lance Taylor <ian@wasabisystems.com> writes:
| > 
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > | 
| > | > The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
| > | > function declaration should be mangled differently from any standard
| > | > C++ construction.  After all, the ABI has provided hook for vendor
| > | > extension. 
| > | 
| > | So you are arguing that this is a bug in g++.
| > 
| > Yes.
| > 
| > | I don't agree.  To me it seems natural that typeof should simply be
| > | replaced by the resulting type when doing name mangling.
| > 
| > Elsewhere, we seem to refrain from "folding".  Which is what I
| > referred to in an earlier message as a schizophrenic position.
| 
| g++ refrains from folding in expressions which appear as template
| arguments.  I don't know whether that is right or wrong.

Yes. Consider but the following case

   struct foo {
     typedef int (*bar)();

     operator bar();

     template<class T>
       operator typeof(T (*)());     
   }; 

if you use typeof to represent int (*)() in the demangled symbol, do
you offer a way to distinguish it from the template instantiation with
T = int (which is a  different function)?

-- Gaby

Re: [c++] Another question about demangler output

[Daniel Jacobowitz]

On Sun, Dec 07, 2003 at 06:05:58AM +0100, Gabriel Dos Reis wrote:
> Ian Lance Taylor <ian@wasabisystems.com> writes:
> 
> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> | 
> | > Ian Lance Taylor <ian@wasabisystems.com> writes:
> | > 
> | > | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> | > | 
> | > | > The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
> | > | > function declaration should be mangled differently from any standard
> | > | > C++ construction.  After all, the ABI has provided hook for vendor
> | > | > extension. 
> | > | 
> | > | So you are arguing that this is a bug in g++.
> | > 
> | > Yes.
> | > 
> | > | I don't agree.  To me it seems natural that typeof should simply be
> | > | replaced by the resulting type when doing name mangling.
> | > 
> | > Elsewhere, we seem to refrain from "folding".  Which is what I
> | > referred to in an earlier message as a schizophrenic position.
> | 
> | g++ refrains from folding in expressions which appear as template
> | arguments.  I don't know whether that is right or wrong.
> 
> Yes. Consider but the following case
> 
>    struct foo {
>      typedef int (*bar)();
> 
>      operator bar();
> 
>      template<class T>
>        operator typeof(T (*)());     
>    }; 
> 
> if you use typeof to represent int (*)() in the demangled symbol, do
> you offer a way to distinguish it from the template instantiation with
> T = int (which is a  different function)?

Currently, an instantiation of the latter for T = double looks like:
  foo::operator double (*)()<double>()

For int it would be:
  foo::operator int (*)()<int>()

which is different from
  foo::operator int (*)()()


With Ian's suggestion they would be, I believe:
  foo::operator typeof(double (*)())<double>()
  foo::operator typeof(int (*)())<int>()
  foo::operator typeof(int (*)())()

How useful that difference is, I'm not sure.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Daniel Jacobowitz <drow@mvista.com> writes:

[...]

| > 
| > Yes. Consider but the following case
| > 
| >    struct foo {
| >      typedef int (*bar)();
| > 
| >      operator bar();
| > 
| >      template<class T>
| >        operator typeof(T (*)());     
| >    }; 
| > 
| > if you use typeof to represent int (*)() in the demangled symbol, do
| > you offer a way to distinguish it from the template instantiation with
| > T = int (which is a  different function)?
| 
| Currently, an instantiation of the latter for T = double looks like:
|   foo::operator double (*)()<double>()

Ah, I see.  That isn't valid C++ either :-)
(Besides the 'double (*)()' thingy that started this thread, there is
no way to specify an explicit template argument for a conversion
function, so the <double> annotation isn't valid either).  Fun, fun.

-- Gaby

Re: [c++] Another question about demangler output

[Daniel Jacobowitz]

On Sun, Dec 07, 2003 at 06:22:15AM +0100, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> [...]
> 
> | > 
> | > Yes. Consider but the following case
> | > 
> | >    struct foo {
> | >      typedef int (*bar)();
> | > 
> | >      operator bar();
> | > 
> | >      template<class T>
> | >        operator typeof(T (*)());     
> | >    }; 
> | > 
> | > if you use typeof to represent int (*)() in the demangled symbol, do
> | > you offer a way to distinguish it from the template instantiation with
> | > T = int (which is a  different function)?
> | 
> | Currently, an instantiation of the latter for T = double looks like:
> |   foo::operator double (*)()<double>()
> 
> Ah, I see.  That isn't valid C++ either :-)
> (Besides the 'double (*)()' thingy that started this thread, there is
> no way to specify an explicit template argument for a conversion
> function, so the <double> annotation isn't valid either).  Fun, fun.

Right.  Is there a valid way in C++ to represent the difference between
these?

Otherwise it's yet another example of the demangler being compelled to
print out invalid C++, which is making everything quite gross.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [c++] Another question about demangler output

[Zack Weinberg]

Daniel Jacobowitz <drow@mvista.com> writes:

>> | > if you use typeof to represent int (*)() in the demangled symbol, do
>> | > you offer a way to distinguish it from the template instantiation with
>> | > T = int (which is a  different function)?
>> | 
>> | Currently, an instantiation of the latter for T = double looks like:
>> |   foo::operator double (*)()<double>()
>> 
>> Ah, I see.  That isn't valid C++ either :-)
>> (Besides the 'double (*)()' thingy that started this thread, there is
>> no way to specify an explicit template argument for a conversion
>> function, so the <double> annotation isn't valid either).  Fun, fun.
>
> Right.  Is there a valid way in C++ to represent the difference between
> these?
>
> Otherwise it's yet another example of the demangler being compelled to
> print out invalid C++, which is making everything quite gross.

I am getting the impression that typedef and template constructs can
produce classes of mangled names that simply cannot be represented by
single expressions in conforming C++.

If this is the case, then the alternatives would seem to be either
printing out demangled expressions that are invalid C++ but
comprehensible to a human, or else making up names as necessary and
printing their definitions too.  The latter seems like too much
trouble, and liable to confuse humans more than the former.

I'd also like to point out that the 'typeof' extension operator would
not be doing its job if it ever appeared in a mangled name.  For a
simple example, given

 template <class T> T foo (T x) { ... }
 int bar;

all three of these:

 bar = foo(bar);
 bar = foo<int>(bar);
 bar = foo<typeof(bar)>(bar);

must cause the instantiation of _Z3fooIiET_S0_, not any more
complicated name.

(Hoom, one is not pleased that the abbreviation mechanism has made the
identifier longer in this instance.  _Z3fooIiEii would be optimal.)

zw

Re: [c++] Another question about demangler output

[Carlo Wood]

On Sun, Dec 07, 2003 at 05:24:46AM +0100, Gabriel Dos Reis wrote:
> The point is this.  "typeof" is a GNU/C++ extension.  Its use in a
> function declaration should be mangled differently from any standard
> C++ construction.  After all, the ABI has provided hook for vendor
> extension. 

At most that would be the case when there is a dependency on
a template parameter - and in the example there is none.
So, the "typeof" disappears and the resulting function will
be equivalent to the case where a typedef had been used,
or nothing at all if that would have been possible (and IS
possible for less complex types than int (*)()).

-- 
Carlo Wood <carlo@alinoe.com>

Re: [c++] Another question about demangler output

[Carlo Wood]

On Sun, Dec 07, 2003 at 06:05:58AM +0100, Gabriel Dos Reis wrote:
>      template<class T>
>        operator typeof(T (*)());     

Here there is a template parameter dependency of the
typeof expression.

-- 
Carlo Wood <carlo@alinoe.com>

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Carlo Wood <carlo@alinoe.com> writes:

| On Sun, Dec 07, 2003 at 06:05:58AM +0100, Gabriel Dos Reis wrote:
| >      template<class T>
| >        operator typeof(T (*)());     
| 
| Here there is a template parameter dependency of the
| typeof expression.

Yes.  That was part of the example.

-- Gaby

Re: [c++] Another question about demangler output

[Carlo Wood]

On Sat, Dec 06, 2003 at 10:30:26PM -0800, Zack Weinberg wrote:
>  template <class T> T foo (T x) { ... }
>  int bar;
>  bar = foo(bar);
[...]
> 
> (Hoom, one is not pleased that the abbreviation mechanism has made the
> identifier longer in this instance.  _Z3fooIiEii would be optimal.)

Not really.  There is a difference between T_ and i, at best you
could replace the S0_ substitution with T_, which is one
character shorter.

Consider

template <class T> T foo (T x) { }
int bar1 = foo(bar1);			// _Z3fooIiET_S0_
template <class T> T foo (int x) { }
int bar2 = foo<int>(bar2);		// _Z3fooIiET_i

This produces both, _Z3fooIiET_i and _Z3fooIiET_S0_

Also note that builtin types are not substituted
at all, so the S0_ is a substitution for T_, not
for i.

For example,

void foo (int, int*, int**) { }

is _Z3fooiPiPS_ and not _Z3fooiPS_PS0_

-- 
Carlo Wood <carlo@alinoe.com>

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

"Zack Weinberg" <zack@codesourcery.com> writes:

| Daniel Jacobowitz <drow@mvista.com> writes:
| 
| >> | > if you use typeof to represent int (*)() in the demangled symbol, do
| >> | > you offer a way to distinguish it from the template instantiation with
| >> | > T = int (which is a  different function)?
| >> | 
| >> | Currently, an instantiation of the latter for T = double looks like:
| >> |   foo::operator double (*)()<double>()
| >> 
| >> Ah, I see.  That isn't valid C++ either :-)
| >> (Besides the 'double (*)()' thingy that started this thread, there is
| >> no way to specify an explicit template argument for a conversion
| >> function, so the <double> annotation isn't valid either).  Fun, fun.
| >
| > Right.  Is there a valid way in C++ to represent the difference between
| > these?
| >
| > Otherwise it's yet another example of the demangler being compelled to
| > print out invalid C++, which is making everything quite gross.
| 
| I am getting the impression that typedef and template constructs can
| produce classes of mangled names that simply cannot be represented by
| single expressions in conforming C++.

Yes, that is the case.

| If this is the case, then the alternatives would seem to be either
| printing out demangled expressions that are invalid C++ but
| comprehensible to a human, or else making up names as necessary and
| printing their definitions too.  The latter seems like too much
| trouble, and liable to confuse humans more than the former.

Well, if it is invlid C++, it is not obvious that it would be
comprehensible to a human :-)  For example, it has been proposed

   struct A {
       operator int (*)()();
   };

But, it is not obvious that that should not have been

   struct A {
      operator int (*())(); 
   }; 

or
  
   struct A {
     int (*operator())();
   };

-- Gaby

Re: [c++] Another question about demangler output

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> "Zack Weinberg" <zack@codesourcery.com> writes:
> | If this is the case, then the alternatives would seem to be either
> | printing out demangled expressions that are invalid C++ but
> | comprehensible to a human, or else making up names as necessary and
> | printing their definitions too.  The latter seems like too much
> | trouble, and liable to confuse humans more than the former.
>
> Well, if it is invlid C++, it is not obvious that it would be
> comprehensible to a human :-)

Good point.  Do you have a better idea?

zw

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

"Zack Weinberg" <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > "Zack Weinberg" <zack@codesourcery.com> writes:
| > | If this is the case, then the alternatives would seem to be either
| > | printing out demangled expressions that are invalid C++ but
| > | comprehensible to a human, or else making up names as necessary and
| > | printing their definitions too.  The latter seems like too much
| > | trouble, and liable to confuse humans more than the former.
| >
| > Well, if it is invlid C++, it is not obvious that it would be
| > comprehensible to a human :-)
| 
| Good point.  Do you have a better idea?

While I'm really uncomfortable with the use of __typeof__ where it was
not present in source code (hence leading to confusions with other
portions), I confess that I cannot propose at the moment something
beyond what Michael presented in his last message.

If anything, those examples prove that the requirement to output
anything but a valid C++ from a fairly non-straightforward C++
constructs is unreasonable.

-- Gaby

Re: [c++] Another question about demangler output

[Geoff Keating]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Ian Lance Taylor <ian@wasabisystems.com> writes:
> 
> [...]
> 
> | This gives _ZN2BBcvPFivEEv which (currently) demangles as
> |     BB::operator int (*)()()
> | 
> | But using a gcc extension, I can do this without a typedef:
> | 
> | class BB { operator typeof (int(*)())(); };
> | BB::operator typeof (int(*)())() { return 0; }
> 
> If you do that, then you might end up accpeting two different
> declarations as same where the token-oriented scheme (ODR) would have
> kept them separate.  That is, you would not be able to differentiate
> 
> tu1.C:
> 
>   struct B { operator typeof(int(*)())(); };
> 
> from
> 
> tu2.C:
> 
>   struct B { typedef int (*foo)(); operator foo(); };
> 
> ODR says they are different.

I don't think it does.  It says you can only have one of them in any
given program, but that's not the same as being different for linkage
purposes.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Geoff Keating <geoffk@geoffk.org> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Ian Lance Taylor <ian@wasabisystems.com> writes:
| > 
| > [...]
| > 
| > | This gives _ZN2BBcvPFivEEv which (currently) demangles as
| > |     BB::operator int (*)()()
| > | 
| > | But using a gcc extension, I can do this without a typedef:
| > | 
| > | class BB { operator typeof (int(*)())(); };
| > | BB::operator typeof (int(*)())() { return 0; }
| > 
| > If you do that, then you might end up accpeting two different
| > declarations as same where the token-oriented scheme (ODR) would have
| > kept them separate.  That is, you would not be able to differentiate
| > 
| > tu1.C:
| > 
| >   struct B { operator typeof(int(*)())(); };
| > 
| > from
| > 
| > tu2.C:
| > 
| >   struct B { typedef int (*foo)(); operator foo(); };
| > 
| > ODR says they are different.
| 
| I don't think it does.

sure, ODR says they are different.

|  It says you can only have one of them in any
| given program,

Precisely!  They are different and cannot simulateneously be present
in a given program.  It is an ODR violation (even if no diagnostic is
required).  If you mangle them differently, then you can catch that
violation. 

-- Gaby

Re: [c++] Another question about demangler output

[Geoff Keating]

> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> Date: 08 Dec 2003 00:18:52 +0100

...
>  It is an ODR violation (even if no diagnostic is
> required).  If you mangle them differently, then you can catch that
> violation. 

Mangling really isn't a good way to detect ODR violations.  If you
mangle two things the same, then you can have two declarations that
don't match and are undetected; if you mangle two things differently,
then you can have two definitions that are undetected.  I think it's
best to choose manglings based on other criteria, like ease of
implementation or standardness.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

Geoff Keating <geoffk@geoffk.org> writes:

| > From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| > Date: 08 Dec 2003 00:18:52 +0100
| 
| ...
| >  It is an ODR violation (even if no diagnostic is
| > required).  If you mangle them differently, then you can catch that
| > violation. 
| 
| Mangling really isn't a good way to detect ODR violations.  If you
| mangle two things the same, then you can have two declarations that
| don't match and are undetected; if you mangle two things differently,
| then you can have two definitions that are undetected.

At least, they don't get used one in place of the other.  I find that
a much lesser evil than treating two different things as same.

-- Gaby

Re: [c++] Another question about demangler output

[Gabriel Dos Reis]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:

[...]

| (4) BB::operator __typeof__(int (*)()) ()
| 
|     I suggest this improvement to (3).  This is my favorite.
| 
| (5) _ZN2BBcvPFivEEv
| 
|     Hey, it's an option, but I don't like it and I doubt that anybody
|     else likes it either.
| 
| My preference order is (4) > (3) > (2) > (1) > (5).

I suppose we can't do better given current state.

-- Gaby

Re: [c++] Another question about demangler output

[Michael Elizabeth Chastain]

How to demangle "_ZN2BBcvPFivEEv"?

(1) BB::operator int (*)()()

    Not legal C++.  I looked at the grammar in Appendix A of TC++PL
    and was surprised to learn that it is not "operator typeid ()",
    but a restriction "operator blah ()" where "blah" can expand
    only to certain types.  But that's the way it is.

(2) BB::operator (int (*)()) ()

    Not legal C++, but closer to something that could be C++.

(3) BB::operator typeof(int (*)()) ()

    This is okay with me.  It is still not legal C++, but it is legal
    with g++ extensions.  That's better than something which can't be
    compiled at all.

(4) BB::operator __typeof__(int (*)()) ()

    I suggest this improvement to (3).  This is my favorite.

(5) _ZN2BBcvPFivEEv

    Hey, it's an option, but I don't like it and I doubt that anybody
    else likes it either.

My preference order is (4) > (3) > (2) > (1) > (5).

GDR is asking a slightly different question, which is how to mangle
"BB::operator __typeof__(int (*)()) ()".  I don't mind mangling that as
"_ZN2BBcvPFivEEv" without the __typeof__ in the mangled name.

I don't know enough about the subtleties of templates to comment on the
cases where template arguments come into play.

Michael C