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

[Daniel Jacobowitz <drow at mvista dot com>]

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.

> 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.

> 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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer