Re: [PATCH]: C++ mangling patch that is about to be committed

[Kevin Buettner <kevinb@cygnus.com>]

On Oct 10, 11:55am, Daniel Berlin wrote:

> Elena Zannoni <ezannoni@cygnus.com> writes:
>
> > BTW, I thought
> > we agreed to leave the do--while construct in the
> > SYMBOL_INIT_DEMANGLED_NAME macro.
> I'd rather not.
> It's not used in if statements, and *never* should be.
> The argument that someone, someday, might want to, just isn't
> convincing, because they shouldn't.

Daniel,

This is really not the way to handle this kind of change.  Elena is
right.  The consensus was to leave the ``do ...  while (0)'' construct
in the SYMBOL_INIT_DEMANGLED_NAME macro.  I believe that turning it
into a proper function was also discussed and is regarded as a viable,
perhaps even superior, alternative.

I know that you don't like the do ... while (0) construct, but it is
not right for you to try to sneak changes eliminating it past the
maintainer multiple times, particularly when you agreed to leave it
in.

Kevin
From ezannoni@cygnus.com Tue Oct 10 10:48:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Daniel Berlin <dberlin@redhat.com>, Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 10:48:00 -0000
Message-id: <14819.22098.949421.575504@kwikemart.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan>
X-SW-Source: 2000-10/msg00042.html
Content-length: 1140

Kevin Buettner writes:
 > On Oct 10, 11:55am, Daniel Berlin wrote:
 > 
 > > Elena Zannoni <ezannoni@cygnus.com> writes:
 > >
 > > > BTW, I thought
 > > > we agreed to leave the do--while construct in the
 > > > SYMBOL_INIT_DEMANGLED_NAME macro.
 > > I'd rather not.
 > > It's not used in if statements, and *never* should be.
 > > The argument that someone, someday, might want to, just isn't
 > > convincing, because they shouldn't.
 > 
 > Daniel,
 > 
 > This is really not the way to handle this kind of change.  Elena is
 > right.  The consensus was to leave the ``do ...  while (0)'' construct
 > in the SYMBOL_INIT_DEMANGLED_NAME macro.  I believe that turning it
 > into a proper function was also discussed and is regarded as a viable,
 > perhaps even superior, alternative.
 > 

Yes. That is what I remember as well.

See: 
http://sources.redhat.com/ml/gdb-patches/2000-08/msg00202.html


Elena

 > I know that you don't like the do ... while (0) construct, but it is
 > not right for you to try to sneak changes eliminating it past the
 > maintainer multiple times, particularly when you agreed to leave it
 > in.
 > 
 > Kevin
 > 
From dberlin@redhat.com Tue Oct 10 11:01:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 11:01:00 -0000
Message-id: <m38zrwa832.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan>
X-SW-Source: 2000-10/msg00043.html
Content-length: 3190

Kevin Buettner <kevinb@cygnus.com> writes:

> On Oct 10, 11:55am, Daniel Berlin wrote:
> 
> > Elena Zannoni <ezannoni@cygnus.com> writes:
> >
> > > BTW, I thought
> > > we agreed to leave the do--while construct in the
> > > SYMBOL_INIT_DEMANGLED_NAME macro.
> > I'd rather not.
> > It's not used in if statements, and *never* should be.
> > The argument that someone, someday, might want to, just isn't
> > convincing, because they shouldn't.
> 
> Daniel,
> 
> This is really not the way to handle this kind of change.  Elena is
> right.  The consensus was to leave the ``do ...  while (0)'' construct
> in the SYMBOL_INIT_DEMANGLED_NAME macro. 

No, there was no consensus, we only really discussed *why* it existed that
way. Nobody provided a convincing reason to keep it the old way, except "It
was that way". 

> I believe that turning it
> into a proper function was also discussed and is regarded as a viable,
> perhaps even superior, alternative.

Feel free to do this.
I'm not playing with symbol tables anymore, I don't have time to wait
for my patches to get approved.

> 
> I know that you don't like the do ... while (0) construct, but it is
> not right for you to try to sneak changes eliminating it past the
> maintainer multiple times, particularly when you agreed to leave it
> in.

I haven't tried to sneak it in, the elimination exists in every
repository i've applied any version of the C++ patches to, so i have to hand
patch every single diff I generate to put it back.

It's not like I can just magically make it reappear in all the
repository copies I have around.

The reality is it exists in the one repository that matters in this
case:
#define SYMBOL_INIT_LANGUAGE_SPECIFIC(symbol,language)                  \
  do {                                                                  \
    SYMBOL_LANGUAGE (symbol) = language;                                \
    if (SYMBOL_LANGUAGE (symbol) == language_cplus                      \
        || SYMBOL_LANGUAGE (symbol) == language_java                    \
        )                                                               \
      {                                                                 \
        SYMBOL_CPLUS_DEMANGLED_NAME (symbol) = NULL;                    \
      }                                                                 \
    else if (SYMBOL_LANGUAGE (symbol) == language_chill)                \
      {                                                                 \
        SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL;                    \
      }                                                                 \
    else                                                                \
      {                                                                 \
        memset (&(symbol)->ginfo.language_specific, 0,                  \
                sizeof ((symbol)->ginfo.language_specific));            \
      }                                                                 \
  } while (0)
                    


I really resent the implication.
I split the patches and did modifications based on the existing set of
patches, which is why the patch has it.

> 
> Kevin