Re: [rfc] plans for linespec.c

[Elena Zannoni <ezannoni at redhat dot com>]

David Carlton writes:
 > I've just submitted the last of a series of patches to linespec.c that
 > begin cleaning up the function decode_line_1.  So now it's 160 lines
 > long instead of 780 lines long, or whatever it was before.  (Of
 > course, the extra lines haven't gone away, they've just moved into
 > their own functions.)
 > 
 > It still has a long way to go; right now, there are a few different
 > ways in which progress can be made.
 > 
 > * The C++ stuff should be broken up into smaller functions, just like
 >   I did with decode_line_1.  It's already divided up into multiple
 >   functions, but some of them are still too large.
 > 

It's a first step, and eventually can be moved to a separate file.

 > * decode_line_1 should be cleaned up still further.  My goal is to
 >   have it eventually look as follows:
 > 
 >   decode_line_1 ()
 >   {
 >     /* Some functions to initialize all the various flags and
 >        variables.  */
 > 
 >     /* Several blocks of the following form, for different values of
 >        XXX.  */
 > 
 >     if (is_XXX ())
 >       return decode_XXX ()
 >   }
 > 
 >   So, basically, some of the predicates have to get simpler, and some
 >   of the initialization code (set_flags, symtab_from_filename) should
 >   move earlier in the function.
 > 

Sounds sane.

 > * Trivial fixes for clarity/ARI: make sure comments end in a period
 >   and two spaces, rename variables so that their name reflects their
 >   use, define the functions in a consistent order, etc.
 > 

yep.

 > These three are all logically independent of each other.  I think
 > Elena suggested that the trivial fixes could be handled as obvious
 > patches once decode_line_1 had gotten simplified a bit; it seems to me
 > that now is an appropriate time to start on that.  And I think I'd
 > rather do the C++ stuff before cleaning up decode_line_1: the logic
 > behind those patches is simpler, and I've finished that in my own
 > private copy of the file whereas I haven't finished all of the further
 > decode_line_1 cleanup in my private copy.
 > 
 > So what makes sense for me to do is:
 > 
 > 1) Start doing some obvious patches that only do stuff like change
 >    formatting, rename variables, etc.; unless Elena or somebody else
 >    objects, I'll post these to gdb-patches but I won't wait for
 >    approval, since they clearly won't change GDB's behavior.
 > 

This is ok, as long as the patches are simple. I.e. better have more
smaller patches, rather than a big one. But you know this already!

 > 2) Start submitting a series of patches to break up decode_compound
 >    and functions that it calls into smaller functions, just like I've
 >    been doing with decode_line_1.  These will, of course, require
 >    approval.
 > 
 > Once all that's done, I'll then get back to cleaning up decode_line_1
 > some more.
 > 
 > How does that sound?
 > 

Sounds good.
Elena


 > David Carlton
 > carlton@math.stanford.edu