Re: [PATCH RFC] Protoize ch-exp.c, core-regset.c

[Kevin Buettner <kevinb at cygnus dot com>]

On Aug 4,  5:31am, Eli Zaretskii wrote:

> > Date: Thu, 3 Aug 2000 12:09:41 -0700
> > From: Kevin Buettner <kevinb@cygnus.com>
> > 
> > Since indent seems to have difficulty with comments in the parameter
> > list, I suspect that this isn't the only case that I'll have to
> > override indent on.  (But if the result looks at all reasonable, I'll
> > prefer indent output over my own hand formatting.)
> [snip]
> >  #if 0
> >  static tree
> > -parse_opt_name_string (allow_all)
> > -     int allow_all;		/* 1 if ALL is allowed as a postfix */
> > +parse_opt_name_string (int allow_all /* 1 if ALL is allowed as a postfix */ )
> 
> FWIW, I think such cases should be edited to move the comment before
> the function definition.  For example:
> 
>   /* Parse the name of an option string.  If ALLOW_ALL is 1, ALL is
>      allowed as a postfix */
>   parse_opt_name_string (int allow_all)
>   {

I too prefer to see the comments describing the parameters before the
function definition.

However, if I add a comment such as in your example, I am doing more
than merely transforming K&R style definitions to ISO-C definitions.
If I do as you propose, I am also ascribing a meaning (via additional
text in the comment) about the function being transformed.

This could be a good thing if I get it right.  But it could be bad
if my comment is incorrect or misleading.

OTOH, that's why I'm posting RFCs and then waiting two days for comments.

Okay... here's what I'll do.  I'll make a reasonable stab at moving
comments embedded in the parameter list to before the function along
with some minimal prefatory remarks.  I ask that maintainers of the
affected files (and anyone else who's interested) look over these
changes to make sure that they aren't objectionable.

Remarks?