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

[Andrew Cagney <ac131313@redhat.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@doc.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