[rfc] plans for linespec.c

[David Carlton <carlton@math.stanford.edu>]

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.

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

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

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.

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?

David Carlton
carlton@math.stanford.edu