From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Daniel Berlin , Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH]: C++ mangling patch that is about to be committed Date: Tue, 10 Oct 2000 10:38:00 -0000 Message-id: <1001010173833.ZM2250@ocotillo.lan> References: <14819.13803.331153.108644@kwikemart.cygnus.com> X-SW-Source: 2000-10/msg00041.html 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. 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 To: Kevin Buettner Cc: Daniel Berlin , Elena Zannoni , 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: <14819.13803.331153.108644@kwikemart.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 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 To: Kevin Buettner 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:01:00 -0000 Message-id: References: <14819.13803.331153.108644@kwikemart.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> X-SW-Source: 2000-10/msg00043.html Content-length: 3190 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". > 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