Re: [PATCH RFC] PARAMS elimination - phase 2

[Andrew Cagney <ac131313 at cygnus dot com>]

Kevin Buettner wrote:
> 
> Below are changes representing phase 2 of the campaign to purge the use
> of PARAMS from the gdb sources.

Can I suggest doing just the automated part of this change and then,
again, give the dust a chance to settle.  The remaining PARAMS that need
hand tweeking can then be done incrementally.

> posted earlier.  (It's identical but for one line.)  After running the
> script, the initial indent was incorrect for declarations appearing in
> structs and within the old pre-ansi parameter declarations.

Can the script remember how much leading white space there was and put
it back afterwards?

>  I fixed
> some of these initial indents by hand.  For the others, I reindented
> the struct declaration in which the declarations appeared.  (I used
> "indent -sbi2" since that seemed to be the convention for the brace
> placement after the struct keyword.) If you look carefully, you'll
> notice that there are a few places where other fields within a struct
> declaration have been reformatted.  I was torn between putting these
> fields back the way they were prior to running indent and leaving them
> in their newly indented state.  In the end I chose the latter option
> of leaving them in their newly indented state.  If you have concerns
> about this, please examine DONT_USE, to_sections, and to_sections_end
> in the patch to target.h below.

While a royal pain in the butt, if the process was automated it can be
lived with.  The main thing is that people with local sources can run
the script over them and preproduce your results.  Things to do include
rewrite target.h into something more like gdbarch.{h,c,sh}.

As an asside, the indent that was used had a bug with how it formatted
structs.  It would format them as either

	struct x
	  {
	    int i;
	  };

	struct x
	{
	  int i;
	};

> Andrew has recommended that I give a one day notice and then, unless
> there are objections, commit the changes.  So... unless I see objections
> to this patch before then, I plan to commit these changes tomorrow
> evening at around 5:00pm MST (which is midnight GMT of Thursday, June 1).

Oops, I was kind of thinking you would do the remainder by hand which
ment you would have been fixing things at the rate of one or two files a
day.  Sorry.

	Andrew