Re: [rfa] symbol hashing, part 2/n - ALL_BLOCK_SYMBOLS

[Elena Zannoni <ezannoni at cygnus dot com>]

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