Re: [RFA] Compile objc-lang.c, objc-exp.tab.c [1/5]

[Andrew Cagney <ac131313 at redhat dot com>]

> On Monday, March 31, 2003, at 03:53 PM, David Carlton wrote:
>
> On Sun, 30 Mar 2003 19:23:08 -0700, Adam Fedor <fedor at doc dot com> said:
>
> Here's my crack at doing [language-specific demangling].
>
> > This patch bothers me: it doesn't handle Java cleanly, and I'm not
> > sure about the 'options' argument to language_demangle.  It seems to
> > me that, at the very least, there should be a java_demangle function
> > defined that takes the options passed in, applies '| DMGL_JAVA' to it,
> > and calls cplus_demangle.

> Sure. That makes sense.
>
> > But I also wanted to double-check: does 'options' really make sense
> > for all language types?  If I'm reading the patch correctly, it looks
> > like Objective C just throws it away.  If that's the case, then I
> > don't think that 'options' should be part of the language vector: if
> > C++ needs it for internal purposes, then C++ could have its own more
> > flexible demangler with that option (which Java could also use), but
> > the version in the language vector should be more restricted.

> Then I should go back to the case where if we know the language is cplus or java, then call cplus_demangle(/java_demangle), otherwise use language_demangle?

Either that, or add a FIXME comment explaining why the options shouldn't 
be there.

The problem with trying to eliminate the parameter is that it also means 
eliminating it from things like fprintf_symbol_filtered().  While likely 
a good idea, it is getting beyond the scope of this immediate patch.

> > Also, I'm not convinced that it's best for the unknown language
> > demangler to always return NULL.  Probably Adam's patch isn't too bad
> > in that regard: it will change the behavior of 'maint demangle', but
> > we can work around that if it's important, and it won't change the
> > behavior of fprintf_symbol_filtered; those are the only places where
> > Adam's patch actually calls language_demangler.  But, given that we
> > don't always reliably know the current language (and could conceivably
> > figure that out via demangling, modulo Java/C++ confusion), I'm not
> > convinced that returning NULL is the right thing.  (Or that it isn't
> > the right thing.)

Hmm, good catch.  Any reason for the unknown language demangler to not 
just do c++ demangling?

Andrew