Re: [rfc] clean up linespec.c

[Elena Zannoni <ezannoni at redhat dot com>]

David Carlton writes:
 > For various reasons, I've been cleaning up linespec.c on a branch; I
 > find the resulting version of linespec.c enough more
 > legible/maintainable that I suspect I'm not the only person who would
 > find it useful.
 > 

You bet!

 > The cleanups consist almost entirely of refactoring rather than
 > changing the behavior: I've broken up large functions into multiple
 > small functions, renamed variable names to make their use clearer, and
 > the like.  Since I was already touching so much of the code, I also
 > fixed up stylistic niceties: using NULL where appropriate, deleting
 > unnecessary casts, fixing comments to end in a period followed by two
 > spaces, and stuff like that.
 > 

cool

 > It turns out that decode_line_1 isn't quite as crazy a function as I'd
 > feared.  There's a reasonable flow of control underneath (well, at
 > least there is once you get rid of the unnecessary goto's), though
 > admittedly the C++ part of the function is still pretty complicated,
 > and the function will always consist of a bunch of special cases.
 > 

Having c++ separated in functions, is a first step in moving C++
support to its own files.....:-)

 > I hope I didn't break anything, though my only real evidence for that
 > is that I didn't get any new regressions on the testsuite.  (I have no
 > idea how comprehensive the testsuite's coverage of linespec is.)

ah, gcov data would be useful here... :-)

 > 
 > So: should I submit an RFA?  Or, more likely, should I start
 > submitting a bunch of RFA's, one at a time?  I suspect it will take a
 > double-digit number of RFA's to break up the changes into manageable
 > chunks, though if you get sick of reading them, you can always approve
 > the changes all at once. :-)
 > 

Yes a bunch of rfa's in rapid succession is the way to go.  I've
looked at your version below, and it looks like the patches would be
fairly obvious. 

I'd reccommend that the other fixes, like reformatting, adding spaces
after periods, etc. could be done after the code movement patches (or
before, whatever is less work for you), as a single patch that spans
the whole file. That would just be obvious.

 > I'm enclosing a copy of my current version of the code after my
 > signature, so you can see what I have to offer.  I won't write up a
 > ChangeLog for the whole thing at once, just ones for each RFA; if I
 > were to write one for the whole thing at once, it would consist almost
 > exclusively of entries like these:
 > 
 > (existing function): Move chunks of code into separate functions;
 > clean up.
 > (new function): New function.
 > 
 > David Carlton
 > carlton@math.stanford.edu
 > 

Elena