From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Daniel Jacobowitz Cc: Andrew Cagney , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [rfa] symbol hashing, part 2/n - ALL_BLOCK_SYMBOLS Date: Fri, 12 Oct 2001 09:08:00 -0000 Message-id: <15303.5930.448714.938333@krustylu.cygnus.com> References: <20011009123457.A28534@nevyn.them.org> <15302.12121.778853.77938@krustylu.cygnus.com> <20011011195450.A22256@nevyn.them.org> <3BC63C81.5000102@cygnus.com> <20011011204828.A24288@nevyn.them.org> X-SW-Source: 2001-10/msg00171.html Daniel Jacobowitz writes: > On Thu, Oct 11, 2001 at 08:42:41PM -0400, Andrew Cagney wrote: > > As you said, it is a double-edged sword. The other edge has a very > > unusual feature. Identify simple mechanical self contained changes and > > often go in as obvious. The review cycle goes down and can often be > > reduced to zero. > > The problem is that I'm working entirely on intrusive changes in code > owned by other people. There are no parts I'm willing to commit as > obvious, and every time I break them up further I introduce > intermediate stages that I have to adequately test. Yes, true. In the printcmd.c file case though I would think that if you did a test run with both changes in, the splitting would be ok. > > > My reading of Elena's comment: > > > > >Yes, I looked ths over and it seems to work, except that I would really > > >prefer the change to printcmd.c split in two. The first bit to > > >rationalize that "if (func)..." code. This would have with it all > > >the indentation changes as well. The code as it is now doesn't really > > >make much sense. So, that looks a good change to me. But it has nothing > > >to do with the new macro. After that change is in, you can introduce > > >the macro in printcmd.c w/o having all the indent changes. > > >It also makes it easier to distinguish a no-op change (the macro) from > > >the other one. > > > > is that you're all approved. > > Well, I need to repost the patch anyway after Elena's comments, so I'll > wait on assuming that. > Just repost the extra conversions to use the macro that we identified. > > Your first commit fixes some messed up logic. It is a cleanup (but > > pretty obvious). It doesn't have anything to do with the (ULGH) macro. > > By keeping it separate it makes it possible to better isolate the > > breakage it could cause when we have to go back (in 6 months) to find a > > bug ;-) > > > > Your second commit is this new (ULGH) macro. The macro (ULGH) shouldn't > > break anything but it is however still a (ULGH) macro. Just include the > > extra tweeks you found. > > > > (If you haven't figured it out, breakpoint.h has a similar (ULGH) macro > > so I'm biteing my tongue on this change :-) > > Heh. I wonder what Andrew thinks of macros? > > Seriously, there's nothing to be done without adding the complexity of > iterators. I want these structures to be treated opaquely, damn it. > For now, macros it is. > Yes, no problem. Elena > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer