This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] plans for linespec.c
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: David Carlton <carlton at math dot stanford dot edu>
- Cc: gdb <gdb at sources dot redhat dot com>, Elena Zannoni <ezannoni at redhat dot com>, Jim Blandy <jimb at redhat dot com>, Fernando Nasser <fnasser at redhat dot com>
- Date: Wed, 8 Jan 2003 09:29:46 -0500
- Subject: Re: [rfc] plans for linespec.c
- References: <ro165t0fvm7.fsf@jackfruit.Stanford.EDU>
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