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

[Michael Snyder <msnyder@redhat.com>]

Daniel Berlin wrote:
> 
> Elena Zannoni <ezannoni@cygnus.com> writes:
> 
> > Daniel,
> >
> > There is an extra change in symtab.h that has nothing to do with the
> > changelog. I think that is part of a different patch.
> No, I missed the changelog entry for it, stupidly.
> 
> > 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.

Umm... Daniel, did you and Elena discuss it?
Overriding her opinion by taking it out of a file
that she maintains and creating a new one that you
maintain does NOT seem to be in the spirit of
maintainership...
From msnyder@redhat.com Tue Oct 10 11:36:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Kevin Buettner <kevinb@cygnus.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 11:36:00 -0000
Message-id: <39E361AD.563F@redhat.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> <m38zrwa832.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00046.html
Content-length: 3675

Daniel Berlin wrote:
> 
> 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".

If it was discussed and there was no consensus, then 
the DEFAULT action should be "no change".  Especially
if the maintainer responsible for that file did not
approve the change.

> > 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'm sorry you feel that way.  Waiting for patches to be approved
is part of the consensus that must exist, to work on a group 
project.  I hope you can get used to it.

> > 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
From ac131313@cygnus.com Tue Oct 10 12:09:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [maint] add FNF to write after approval list
Date: Tue, 10 Oct 2000 12:09:00 -0000
Message-id: <39E1EB29.415C3059@cygnus.com>
X-SW-Source: 2000-10/msg00047.html
Content-length: 60

Just FYI,

I see no reason for this to not occure.

	Andrew
From dberlin@redhat.com Tue Oct 10 12:37:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Michael Snyder <msnyder@redhat.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 12:37:00 -0000
Message-id: <m3zokc8p3c.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <39E35F1D.6070@redhat.com>
X-SW-Source: 2000-10/msg00048.html
Content-length: 2234

Michael Snyder <msnyder@redhat.com> writes:

> Daniel Berlin wrote:
> > 
> > Elena Zannoni <ezannoni@cygnus.com> writes:
> > 
> > > Daniel,
> > >
> > > There is an extra change in symtab.h that has nothing to do with the
> > > changelog. I think that is part of a different patch.
> > No, I missed the changelog entry for it, stupidly.
> > 
> > > 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.
> 
> Umm... Daniel, did you and Elena discuss it?

Elena didn't participate in that discussion, it was held on
gdb-patches in clear view.

> Overriding her opinion by taking it out of a file
> that she maintains and creating a new one that you
> maintain does NOT seem to be in the spirit of
> maintainership...
Err, i'm not.
It's always been in symtab.h
I don't plan on moving that macro to cp-support.h,.
What made you think it was being taken out of a file she maintains,
and moved to one i maintain.
Elena is the backup maintainer.
THat's part of the whole problem.
The maintainer hasn't participated in maintaining the file in a while.
Like I said, since this stuff isn't in my maintainership, i'm not
fixing it anymore.
Someone else can fix it, whether it affects C++ support or not.
That is what part of being  a maintainer is, right? Maintaining?

It's interesting that you seem to be bashing my plan to move the C++
support specific things to cp-support.c, out of places they don't
belong (this is what i'm assuming you think i'm doing when you say
moving things out of a file someone else maintains, and into one i
maintain), since nobody maintains them but me, because they are C++ specific.

I'm expected to look at problems related to them, and fix them, rather
than the person whose maintainership they do fall under, yet I have
to get the patches approved by other people, since i'm not supposed to
maintain them. So i'm to maintain them, but not maintain them.  Weird.
Nobody else has fixed this stuff in years, so it's not a matter of me
just getting to it first.


--Dan