RFA: change K&R to ISO

RFA: change K&R to ISO

[Tom Tromey]

I noticed some K&R-style function definitions.

This seemed weird, so this patch changes them to ISO style.

Built & regtested on x86-64 (compile farm).

Please review.

Tom

:ADDPATCH java:

2008-09-26  Tom Tromey  <tromey@redhat.com>

	* jv-exp.y (insert_exp): Define using ISO syntax.
	(copy_exp): Likewise.
	(push_expression_name): Likewise.
	(push_fieldnames): Likewise.
	(java_type_from_name): Likewise.
	(yyerror): Likewise.
	(yylex): Likewise.
	(parse_number): Likewise.

diff --git a/gdb/jv-exp.y b/gdb/jv-exp.y
index ff9a7a1..12bf517 100644
--- a/gdb/jv-exp.y
+++ b/gdb/jv-exp.y
@@ -693,11 +693,7 @@ Expression:
 /*** Needs some error checking for the float case ***/
 
 static int
-parse_number (p, len, parsed_float, putithere)
-     char *p;
-     int len;
-     int parsed_float;
-     YYSTYPE *putithere;
+parse_number (char *p, int len, int parsed_float, YYSTYPE *putithere)
 {
   ULONGEST n = 0;
   ULONGEST limit, limit_div_base;
@@ -851,7 +847,7 @@ static const struct token tokentab2[] =
 /* Read one token, getting characters through lexptr.  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c;
   int namelen;
@@ -1197,8 +1193,7 @@ yylex ()
 }
 
 void
-yyerror (msg)
-     char *msg;
+yyerror (char *msg)
 {
   if (prev_lexptr)
     lexptr = prev_lexptr;
@@ -1210,9 +1205,7 @@ yyerror (msg)
 }
 
 static struct type *
-java_type_from_name (name)
-     struct stoken name;
- 
+java_type_from_name (struct stoken name)
 {
   char *tmp = copy_name (name);
   struct type *typ = java_lookup_class (tmp);
@@ -1271,8 +1264,7 @@ push_variable (struct stoken name)
    qualified name (has '.'), generate a field access for each part. */
 
 static void
-push_fieldnames (name)
-     struct stoken name;
+push_fieldnames (struct stoken name)
 {
   int i;
   struct stoken token;
@@ -1363,8 +1355,7 @@ push_qualified_expression_name (struct stoken name, int dot_index)
    Handle VAR, TYPE, TYPE.FIELD1....FIELDN and VAR.FIELD1....FIELDN. */
 
 static void
-push_expression_name (name)
-     struct stoken name;
+push_expression_name (struct stoken name)
 {
   char *tmp;
   struct type *typ;
@@ -1418,9 +1409,7 @@ push_expression_name (name)
    into a freshly malloc'ed struct expression.  Its language_defn is set
    to null.  */
 static struct expression *
-copy_exp (expr, endpos)
-     struct expression *expr;
-     int endpos;
+copy_exp (struct expression *expr, int endpos)
 {
   int len = length_of_subexp (expr, endpos);
   struct expression *new
@@ -1434,9 +1423,7 @@ copy_exp (expr, endpos)
 
 /* Insert the expression NEW into the current expression (expout) at POS.  */
 static void
-insert_exp (pos, new)
-     int pos;
-     struct expression *new;
+insert_exp (int pos, struct expression *new)
 {
   int newlen = new->nelts;
 

Re: RFA: change K&R to ISO

[Pedro Alves]

On Saturday 27 September 2008 00:30:50, Tom Tromey wrote:
> I noticed some K&R-style function definitions.

> 2008-09-26  Tom Tromey  <tromey@redhat.com>
>
> 	* jv-exp.y (insert_exp): Define using ISO syntax.
> 	(copy_exp): Likewise.
> 	(push_expression_name): Likewise.
> 	(push_fieldnames): Likewise.
> 	(java_type_from_name): Likewise.
> 	(yyerror): Likewise.
> 	(yylex): Likewise.
> 	(parse_number): Likewise.

:REVIEWMAIL:

OK.  Obvious even nowadays?

-- 
Pedro Alves

Re: RFA: change K&R to ISO

[Joel Brobecker]

On Sat, Sep 27, 2008 at 12:49:06AM +0100, Pedro Alves wrote:
> > I noticed some K&R-style function definitions.
[...]
> OK.  Obvious even nowadays?

I would say so.

-- 
Joel

Re: RFA: change K&R to ISO

[Tom Tromey]

Tom> I noticed some K&R-style function definitions.

Pedro> OK.  Obvious even nowadays?

I considered that, but I tend to be conservative when applying the
obvious rule.  Usually I think I only use it for clearly incorrect
comments, typos, and build breakages.  That said, I'm happy to follow
whatever the gdb guidelines actually are.

Tom

Re: RFA: change K&R to ISO

[Joel Brobecker]

> Pedro> OK.  Obvious even nowadays?
> 
> I considered that, but I tend to be conservative when applying the
> obvious rule.  Usually I think I only use it for clearly incorrect
> comments, typos, and build breakages.  That said, I'm happy to follow
> whatever the gdb guidelines actually are.

I think it's always better to be more conservative than the opposite,
particularly when the change contains a lot of hunks.  But on the other
hand, my approach (and this is my opinion, not necessarily the opinion
of the GDB maintainers) has always been that it's not the end of the world
if one small change that was considered obvious by a contributor wasn't
so obvious to someone else. It's pretty easy to back out a change after
the fact.

Back the specific issue of converting from K&R to ISO: The change is
fairly mechanical, so the chances of making a mistake are really small.
Also, adding a review-before-commit step adds to the "cost" of making
the change. Allowing contributors to commit these changes using the
obvious rule can only encourage more of these changes.

-- 
Joel