From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Daniel Berlin Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [PATCH]: C++ mangling patch that is about to be committed Date: Tue, 10 Oct 2000 11:25:00 -0000 Message-id: <39E35F1D.6070@redhat.com> References: <14819.13803.331153.108644@kwikemart.cygnus.com> X-SW-Source: 2000-10/msg00045.html Daniel Berlin wrote: > > Elena Zannoni 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 To: Daniel Berlin Cc: Kevin Buettner , Elena Zannoni , 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: <14819.13803.331153.108644@kwikemart.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> X-SW-Source: 2000-10/msg00046.html Content-length: 3675 Daniel Berlin wrote: > > Kevin Buettner writes: > > > On Oct 10, 11:55am, Daniel Berlin wrote: > > > > > Elena Zannoni 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 To: GDB Patches 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 To: Michael Snyder Cc: Elena Zannoni , 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: References: <14819.13803.331153.108644@kwikemart.cygnus.com> <39E35F1D.6070@redhat.com> X-SW-Source: 2000-10/msg00048.html Content-length: 2234 Michael Snyder writes: > Daniel Berlin wrote: > > > > Elena Zannoni 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