This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
[rfc] plans for linespec.c
- From: David Carlton <carlton at math dot stanford dot edu>
- To: gdb <gdb at sources dot redhat dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>, Jim Blandy <jimb at redhat dot com>, Fernando Nasser <fnasser at redhat dot com>
- Date: 07 Jan 2003 14:22:40 -0800
- Subject: [rfc] plans for linespec.c
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