New ARI warning Sat Mar 12 01:53:29 UTC 2011

New ARI warning Sat Mar 12 01:53:29 UTC 2011

[GDB Administrator]

76a77
> gdb/breakpoint.c:11955: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/breakpoint.c:11955:all_tracepoints ()
259a261,262
> gdb/f-exp.y:922: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/f-exp.y:922:match_string_literal ()
> gdb/f-exp.y:954: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/f-exp.y:954:yylex ()
343a347
> gdb/hppa-tdep.h:244: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/hppa-tdep.h:244:hppa_init_objfile_priv_data (struct objfile *objfile);
403a408
> gdb/inferior.h:370: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/inferior.h:370:get_displaced_step_closure_by_addr (CORE_ADDR addr);
528a534
> gdb/m2-exp.y:811: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/m2-exp.y:811:yylex ()
561a568,573
> gdb/mep-tdep.c:848: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/mep-tdep.c:848:current_me_module ()
> gdb/mep-tdep.c:871: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/mep-tdep.c:871:current_options ()
> gdb/mep-tdep.c:888: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/mep-tdep.c:888:current_cop_data_bus_width ()
> gdb/mep-tdep.c:897: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/mep-tdep.c:897:current_cr_names ()
> gdb/mep-tdep.c:909: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/mep-tdep.c:909:current_cr_is_float ()
> gdb/mep-tdep.c:921: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/mep-tdep.c:921:current_ccr_names ()
676a689,692
> gdb/objc-exp.y:111: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/objc-exp.y:111:yyparse (void);
> gdb/objc-exp.y:114: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/objc-exp.y:114:yylex (void);
> gdb/objc-exp.y:117: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/objc-exp.y:117:yyerror (char *);
> gdb/objc-exp.y:154: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/objc-exp.y:154:parse_number (char *, int, int, YYSTYPE *);
692a709
> gdb/objc-exp.y:1221: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/objc-exp.y:1221:yylex ()
724a742,743
> gdb/p-exp.y:121: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/p-exp.y:121:yyerror (char *);
> gdb/p-exp.y:158: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/p-exp.y:158:parse_number (char *, int, int, YYSTYPE *);
733a753
> gdb/p-exp.y:1123: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/p-exp.y:1123:yylex ()
831a852,855
> gdb/python/py-evts.c:45: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/python/py-evts.c:45:gdbpy_initialize_py_events ()
> gdb/python/py-prettyprint.c:397: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/python/py-prettyprint.c:397:push_dummy_python_frame ()
> gdb/python/py-stopevent.h:32: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/python/py-stopevent.h:32:create_breakpoint_event_object (PyObject *breakpoint);
> gdb/python/py-stopevent.h:35: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/python/py-stopevent.h:35:create_signal_event_object (enum target_signal stop_signal);
904a929
> gdb/remote.c:3115: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/remote.c:3115:send_interrupt_sequence ()
1011a1037
> gdb/solib-pa64.c:80: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/solib-pa64.c:80:read_dynamic_info (asection *dyninfo_sect, dld_cache_t *dld_cache_p);
1134a1161
> gdb/tracepoint.c:221: code: no parameter function: Function having no parameter should be declared with funcname (void).
gdb/tracepoint.c:221:current_trace_status ()
1234a1262
> gdb/varobj.c:300: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/varobj.c:300:varobj_add_child (struct varobj *var, const char *name, struct value *value);
1236a1265
> gdb/varobj.h:171: code: function call in first column: Function name in first column should be restricted to function implementation
gdb/varobj.h:171:varobj_set_visualizer (struct varobj *var, const char *visualizer);
1296,1298d1324
< gdb/xtensa-tdep.c:124: code: inline: Do not use the inline attribute; since the compiler generally ignores this, better algorithm selection is needed to improved performance
gdb/xtensa-tdep.c:124:static inline int
< gdb/xtensa-tdep.c:165: code: inline: Do not use the inline attribute; since the compiler generally ignores this, better algorithm selection is needed to improved performance
gdb/xtensa-tdep.c:165:static inline unsigned long
< gdb/xtensa-tdep.c:175: code: inline: Do not use the inline attribute; since the compiler generally ignores this, better algorithm selection is needed to improved performance
gdb/xtensa-tdep.c:175:static inline void
1300d1325
< gdb/xtensa-tdep.c:740: code: inline: Do not use the inline attribute; since the compiler generally ignores this, better algorithm selection is needed to improved performance
gdb/xtensa-tdep.c:740:static inline

RE: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pierre Muller]

  This is the consequence of the two new ARI rules I added:
http://sourceware.org/ml/gdb-patches/2011-03/msg00654.html

  As I just introduced these new rules,
I felt that it would be cheating to
use OBVIOUS rule as we normally do to fix 
a ARI regression...
  This is why I will submit shortly two patches
to remove all those new warnings.

Pierre Muller
as ARI maintainer.


> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de GDB Administrator
> Envoyé : samedi 12 mars 2011 02:53
> À : gdb-patches@sourceware.org
> Objet : New ARI warning Sat Mar 12 01:53:29 UTC 2011
> 
> 76a77
> > gdb/breakpoint.c:11955: code: no parameter function: Function having
> no parameter should be declared with funcname (void).
> gdb/breakpoint.c:11955:all_tracepoints ()
> 259a261,262
> > gdb/f-exp.y:922: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/f-exp.y:922:match_string_literal ()
> > gdb/f-exp.y:954: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/f-exp.y:954:yylex ()
> 343a347
> > gdb/hppa-tdep.h:244: code: function call in first column: Function
> name in first column should be restricted to function implementation
> gdb/hppa-tdep.h:244:hppa_init_objfile_priv_data (struct objfile
> *objfile);
> 403a408
> > gdb/inferior.h:370: code: function call in first column: Function
> name in first column should be restricted to function implementation
> gdb/inferior.h:370:get_displaced_step_closure_by_addr (CORE_ADDR addr);
> 528a534
> > gdb/m2-exp.y:811: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/m2-exp.y:811:yylex ()
> 561a568,573
> > gdb/mep-tdep.c:848: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/mep-tdep.c:848:current_me_module ()
> > gdb/mep-tdep.c:871: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/mep-tdep.c:871:current_options ()
> > gdb/mep-tdep.c:888: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/mep-tdep.c:888:current_cop_data_bus_width ()
> > gdb/mep-tdep.c:897: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/mep-tdep.c:897:current_cr_names ()
> > gdb/mep-tdep.c:909: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/mep-tdep.c:909:current_cr_is_float ()
> > gdb/mep-tdep.c:921: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/mep-tdep.c:921:current_ccr_names ()
> 676a689,692
> > gdb/objc-exp.y:111: code: function call in first column: Function
> name in first column should be restricted to function implementation
> gdb/objc-exp.y:111:yyparse (void);
> > gdb/objc-exp.y:114: code: function call in first column: Function
> name in first column should be restricted to function implementation
> gdb/objc-exp.y:114:yylex (void);
> > gdb/objc-exp.y:117: code: function call in first column: Function
> name in first column should be restricted to function implementation
> gdb/objc-exp.y:117:yyerror (char *);
> > gdb/objc-exp.y:154: code: function call in first column: Function
> name in first column should be restricted to function implementation
> gdb/objc-exp.y:154:parse_number (char *, int, int, YYSTYPE *);
> 692a709
> > gdb/objc-exp.y:1221: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/objc-exp.y:1221:yylex ()
> 724a742,743
> > gdb/p-exp.y:121: code: function call in first column: Function name
> in first column should be restricted to function implementation
> gdb/p-exp.y:121:yyerror (char *);
> > gdb/p-exp.y:158: code: function call in first column: Function name
> in first column should be restricted to function implementation
> gdb/p-exp.y:158:parse_number (char *, int, int, YYSTYPE *);
> 733a753
> > gdb/p-exp.y:1123: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/p-exp.y:1123:yylex ()
> 831a852,855
> > gdb/python/py-evts.c:45: code: no parameter function: Function having
> no parameter should be declared with funcname (void).
> gdb/python/py-evts.c:45:gdbpy_initialize_py_events ()
> > gdb/python/py-prettyprint.c:397: code: no parameter function:
> Function having no parameter should be declared with funcname (void).
> gdb/python/py-prettyprint.c:397:push_dummy_python_frame ()
> > gdb/python/py-stopevent.h:32: code: function call in first column:
> Function name in first column should be restricted to function
> implementation
> gdb/python/py-stopevent.h:32:create_breakpoint_event_object (PyObject
> *breakpoint);
> > gdb/python/py-stopevent.h:35: code: function call in first column:
> Function name in first column should be restricted to function
> implementation
> gdb/python/py-stopevent.h:35:create_signal_event_object (enum
> target_signal stop_signal);
> 904a929
> > gdb/remote.c:3115: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/remote.c:3115:send_interrupt_sequence ()
> 1011a1037
> > gdb/solib-pa64.c:80: code: function call in first column: Function
> name in first column should be restricted to function implementation
> gdb/solib-pa64.c:80:read_dynamic_info (asection *dyninfo_sect,
> dld_cache_t *dld_cache_p);
> 1134a1161
> > gdb/tracepoint.c:221: code: no parameter function: Function having no
> parameter should be declared with funcname (void).
> gdb/tracepoint.c:221:current_trace_status ()
> 1234a1262
> > gdb/varobj.c:300: code: function call in first column: Function name
> in first column should be restricted to function implementation
> gdb/varobj.c:300:varobj_add_child (struct varobj *var, const char
> *name, struct value *value);
> 1236a1265
> > gdb/varobj.h:171: code: function call in first column: Function name
> in first column should be restricted to function implementation
> gdb/varobj.h:171:varobj_set_visualizer (struct varobj *var, const char
> *visualizer);
> 1296,1298d1324
> < gdb/xtensa-tdep.c:124: code: inline: Do not use the inline attribute;
> since the compiler generally ignores this, better algorithm selection
> is needed to improved performance
> gdb/xtensa-tdep.c:124:static inline int
> < gdb/xtensa-tdep.c:165: code: inline: Do not use the inline attribute;
> since the compiler generally ignores this, better algorithm selection
> is needed to improved performance
> gdb/xtensa-tdep.c:165:static inline unsigned long
> < gdb/xtensa-tdep.c:175: code: inline: Do not use the inline attribute;
> since the compiler generally ignores this, better algorithm selection
> is needed to improved performance
> gdb/xtensa-tdep.c:175:static inline void
> 1300d1325
> < gdb/xtensa-tdep.c:740: code: inline: Do not use the inline attribute;
> since the compiler generally ignores this, better algorithm selection
> is needed to improved performance
> gdb/xtensa-tdep.c:740:static inline

[RFA] Fix ARI warning about function call in first column (was : New ARI warning Sat Mar 12 01:53:29 UTC 2011)

[Pierre Muller]

This second patch fixes:
> gdb/hppa-tdep.h:244: code: function call in first column: Function name in
first column should be restricted to function implementation
gdb/hppa-tdep.h:244:hppa_init_objfile_priv_data (struct objfile *objfile);
and other occurrences of same new warning.

OK to apply?

Pierre Muller
as ARI maintainer.


2011-03-13  Pierre Muller  <muller@ics.u-strasbg.fr>

	Fix ARI warning about functions without parameters that do not
	use (void).
	* breakpoint.c (all_tracepoints): Replace () by (void).
	* f-exp.y (match_string_literal): Ditto.
	(yylex): Ditto.
	* m2-exp.y (yylex): Ditto.
	* mep-tdep.c (current_me_module): Ditto.
	(current_options): Ditto.
	(current_cop_data_bus_width): Ditto.
	(current_cr_names): Ditto.
	(current_cr_is_float): Ditto.
	(current_ccr_names): Ditto.
	* objc-exp.y (yylex): Ditto.
	* p-exp.y (yylex): Ditto.
	* remote.c (send_interrupt_sequence): Ditto.
	* tracepoint.c (current_trace_status): Ditto.
	* python/py-evts.c (gdbpy_initialize_py_events): Ditto.
	* python/py-prettyprint.c (push_dummy_python_frame): Ditto.

Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.550
diff -u -p -r1.550 breakpoint.c
--- breakpoint.c	10 Mar 2011 18:33:59 -0000	1.550
+++ breakpoint.c	11 Mar 2011 15:18:06 -0000
@@ -11952,7 +11952,7 @@ save_tracepoints_command (char *args, in
 /* Create a vector of all tracepoints.  */
 
 VEC(breakpoint_p) *
-all_tracepoints ()
+all_tracepoints (void)
 {
   VEC(breakpoint_p) *tp_vec = 0;
   struct breakpoint *tp;
Index: f-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/f-exp.y,v
retrieving revision 1.36
diff -u -p -r1.36 f-exp.y
--- f-exp.y	7 Jan 2011 19:36:16 -0000	1.36
+++ f-exp.y	11 Mar 2011 15:18:06 -0000
@@ -919,7 +919,7 @@ growbuf_by_size (count)
    a string, it is simply doubled (I.E. 'this''is''one''string') */
 
 static int
-match_string_literal ()
+match_string_literal (void)
 {
   char *tokptr = lexptr;
 
@@ -951,7 +951,7 @@ match_string_literal ()
 /* Read one token, getting characters through lexptr.  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c;
   int namelen;
Index: m2-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/m2-exp.y,v
retrieving revision 1.33
diff -u -p -r1.33 m2-exp.y
--- m2-exp.y	9 Jan 2011 03:20:33 -0000	1.33
+++ m2-exp.y	11 Mar 2011 15:18:06 -0000
@@ -808,7 +808,7 @@ static struct keyword keytab[] =
    compatible  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c;
   int namelen;
Index: mep-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mep-tdep.c,v
retrieving revision 1.29
diff -u -p -r1.29 mep-tdep.c
--- mep-tdep.c	10 Jan 2011 17:14:12 -0000	1.29
+++ mep-tdep.c	11 Mar 2011 15:18:06 -0000
@@ -845,7 +845,7 @@ mep_pseudo_cr_index (int pseudo)
    from the ELF header's e_flags field of the current executable
    file.  */
 static CONFIG_ATTR
-current_me_module ()
+current_me_module (void)
 {
   if (target_has_registers)
     {
@@ -868,7 +868,7 @@ current_me_module ()
    then use the 'module_opt' field we computed when we build the
    gdbarch object for this module.  */
 static unsigned int
-current_options ()
+current_options (void)
 {
   if (target_has_registers)
     {
@@ -885,7 +885,7 @@ current_options ()
 /* Return the width of the current me_module's coprocessor data bus,
    in bits.  This is either 32 or 64.  */
 static int
-current_cop_data_bus_width ()
+current_cop_data_bus_width (void)
 {
   return me_module_cop_data_bus_width (current_me_module ());
 }
@@ -894,7 +894,7 @@ current_cop_data_bus_width ()
 /* Return the keyword table of coprocessor general-purpose register
    names appropriate for the me_module we're dealing with.  */
 static CGEN_KEYWORD *
-current_cr_names ()
+current_cr_names (void)
 {
   const CGEN_HW_ENTRY *hw
     = me_module_register_set (current_me_module (), "h-cr-", HW_H_CR);
@@ -906,7 +906,7 @@ current_cr_names ()
 /* Return non-zero if the coprocessor general-purpose registers are
    floating-point values, zero otherwise.  */
 static int
-current_cr_is_float ()
+current_cr_is_float (void)
 {
   const CGEN_HW_ENTRY *hw
     = me_module_register_set (current_me_module (), "h-cr-", HW_H_CR);
@@ -918,7 +918,7 @@ current_cr_is_float ()
 /* Return the keyword table of coprocessor control register names
    appropriate for the me_module we're dealing with.  */
 static CGEN_KEYWORD *
-current_ccr_names ()
+current_ccr_names (void)
 {
   const CGEN_HW_ENTRY *hw
     = me_module_register_set (current_me_module (), "h-ccr-", HW_H_CCR);
Index: objc-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/objc-exp.y,v
retrieving revision 1.41
diff -u -p -r1.41 objc-exp.y
--- objc-exp.y	10 Jan 2011 20:38:49 -0000	1.41
+++ objc-exp.y	11 Mar 2011 15:18:06 -0000
@@ -1218,7 +1218,7 @@ static const struct token tokentab2[] =
 /* Read one token, getting characters through lexptr.  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c, tokchr;
   int namelen;
Index: p-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/p-exp.y,v
retrieving revision 1.54
diff -u -p -r1.54 p-exp.y
--- p-exp.y	17 Jan 2011 10:34:51 -0000	1.54
+++ p-exp.y	11 Mar 2011 15:18:06 -0000
@@ -1120,7 +1120,7 @@ static int last_was_structop;
 /* Read one token, getting characters through lexptr.  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c;
   int namelen;
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.438
diff -u -p -r1.438 remote.c
--- remote.c	8 Mar 2011 12:46:51 -0000	1.438
+++ remote.c	11 Mar 2011 15:18:07 -0000
@@ -3112,7 +3112,7 @@ struct start_remote_args
 
 /* Send interrupt_sequence to remote target.  */
 static void
-send_interrupt_sequence ()
+send_interrupt_sequence (void)
 {
   if (interrupt_sequence_mode == interrupt_sequence_control_c)
     serial_write (remote_desc, "\x03", 1);
Index: tracepoint.c
===================================================================
RCS file: /cvs/src/src/gdb/tracepoint.c,v
retrieving revision 1.216
diff -u -p -r1.216 tracepoint.c
--- tracepoint.c	10 Mar 2011 18:33:59 -0000	1.216
+++ tracepoint.c	11 Mar 2011 15:18:08 -0000
@@ -218,7 +218,7 @@ char *stop_reason_names[] = {
 };
 
 struct trace_status *
-current_trace_status ()
+current_trace_status (void)
 {
   return &trace_status;
 }
Index: python/py-evts.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-evts.c,v
retrieving revision 1.1
diff -u -p -r1.1 py-evts.c
--- python/py-evts.c	5 Feb 2011 05:27:23 -0000	1.1
+++ python/py-evts.c	11 Mar 2011 15:18:08 -0000
@@ -42,7 +42,7 @@ add_new_registry (eventregistry_object *
 }
 
 void
-gdbpy_initialize_py_events ()
+gdbpy_initialize_py_events (void)
 {
   gdb_py_events.module = Py_InitModule ("events", NULL);
 
Index: python/py-prettyprint.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-prettyprint.c,v
retrieving revision 1.23
diff -u -p -r1.23 py-prettyprint.c
--- python/py-prettyprint.c	1 Mar 2011 21:54:53 -0000	1.23
+++ python/py-prettyprint.c	11 Mar 2011 15:18:08 -0000
@@ -394,7 +394,7 @@ py_restore_tstate (void *p)
 /* Create a dummy PyFrameObject, needed to work around
    a Python-2.4 bug with generators.  */
 static PyObject *
-push_dummy_python_frame ()
+push_dummy_python_frame (void)
 {
   PyObject *empty_string, *null_tuple, *globals;
   PyCodeObject *code;

[RFA] Fix ARI warnings about function with no parameters ( RE: New ARI warning Sat Mar 12 01:53:29 UTC 2011)

[Pierre Muller]

First patch to fix new ARI warnings about
functions having no parameters,
using () instead of (void).

OK to apply?

Pierre Muller
as ARI maintainer

2011-03-13  Pierre Muller  <muller@ics.u-strasbg.fr>

	Fix ARI warning about function names in first column.
	Put prototype declaration on same line as return type.
	* objc-exp.y: Ditto.
	* p-exp.y: Ditto.
	For long function names, indent prototype declarations to avoid
	function name in first column.
	* hppa-tdep.h: Ditto.
	* inferior.h: Ditto.
	* solib-pa64.c: Ditto.
	* varobj.c: Ditto.
	* varobj.h: Ditto.
	* python/py-stopevent.h: Ditto.

Index: hppa-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.h,v
retrieving revision 1.41
diff -u -p -r1.41 hppa-tdep.h
--- hppa-tdep.h	9 Jan 2011 03:08:55 -0000	1.41
+++ hppa-tdep.h	11 Mar 2011 15:04:44 -0000
@@ -241,7 +241,7 @@ extern struct minimal_symbol *
                                    enum unwind_stub_types stub_type);
 
 extern struct hppa_objfile_private *
-hppa_init_objfile_priv_data (struct objfile *objfile);
+  hppa_init_objfile_priv_data (struct objfile *objfile);
 
 extern int hppa_in_solib_call_trampoline (struct gdbarch *gdbarch,
 					  CORE_ADDR pc, char *name);
Index: inferior.h
===================================================================
RCS file: /cvs/src/src/gdb/inferior.h,v
retrieving revision 1.152
diff -u -p -r1.152 inferior.h
--- inferior.h	26 Feb 2011 02:07:08 -0000	1.152
+++ inferior.h	11 Mar 2011 15:04:44 -0000
@@ -367,7 +367,7 @@ void displaced_step_dump_bytes (struct u
                                 const gdb_byte *buf, size_t len);
 
 struct displaced_step_closure*
-get_displaced_step_closure_by_addr (CORE_ADDR addr);
+  get_displaced_step_closure_by_addr (CORE_ADDR addr);
 

 /* Possible values for gdbarch_call_dummy_location.  */
 #define ON_STACK 1
Index: objc-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/objc-exp.y,v
retrieving revision 1.41
diff -u -p -r1.41 objc-exp.y
--- objc-exp.y	10 Jan 2011 20:38:49 -0000	1.41
+++ objc-exp.y	11 Mar 2011 15:04:44 -0000
@@ -107,14 +107,11 @@
 #define	YYDEBUG	0		/* Default to no yydebug support.
*/
 #endif
 
-int
-yyparse (void);
+int yyparse (void);
 
-static int
-yylex (void);
+static int yylex (void);
 
-void
-yyerror (char *);
+void yyerror (char *);
 
 %}
 
@@ -150,8 +147,7 @@ yyerror (char *);
 
 %{
 /* YYSTYPE gets defined by %union.  */
-static int
-parse_number (char *, int, int, YYSTYPE *);
+static int parse_number (char *, int, int, YYSTYPE *);
 %}
 
 %type <voidval> exp exp1 type_exp start variable qualified_name lcurly
Index: p-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/p-exp.y,v
retrieving revision 1.54
diff -u -p -r1.54 p-exp.y
--- p-exp.y	17 Jan 2011 10:34:51 -0000	1.54
+++ p-exp.y	11 Mar 2011 15:04:44 -0000
@@ -117,8 +117,7 @@ int yyparse (void);
 
 static int yylex (void);
 
-void
-yyerror (char *);
+void yyerror (char *);
 
 static char * uptok (char *, int);
 %}
@@ -154,8 +153,7 @@ static char * uptok (char *, int);
 
 %{
 /* YYSTYPE gets defined by %union */
-static int
-parse_number (char *, int, int, YYSTYPE *);
+static int parse_number (char *, int, int, YYSTYPE *);
 
 static struct type *current_type;
 static struct internalvar *intvar;
Index: solib-pa64.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-pa64.c,v
retrieving revision 1.29
diff -u -p -r1.29 solib-pa64.c
--- solib-pa64.c	11 Jan 2011 21:53:24 -0000	1.29
+++ solib-pa64.c	11 Mar 2011 15:04:44 -0000
@@ -77,7 +77,7 @@ dld_cache_t;
 static dld_cache_t dld_cache;
 
 static int
-read_dynamic_info (asection *dyninfo_sect, dld_cache_t *dld_cache_p);
+  read_dynamic_info (asection *dyninfo_sect, dld_cache_t *dld_cache_p);
 
 static void
 pa64_relocate_section_addresses (struct so_list *so,
Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.172
diff -u -p -r1.172 varobj.c
--- varobj.c	5 Mar 2011 22:02:47 -0000	1.172
+++ varobj.c	11 Mar 2011 15:04:44 -0000
@@ -297,7 +297,7 @@ static int is_root_p (struct varobj *var
 #if HAVE_PYTHON
 
 static struct varobj *
-varobj_add_child (struct varobj *var, const char *name, struct value
*value);
+  varobj_add_child (struct varobj *var, const char *name, struct value
*value);
 
 #endif /* HAVE_PYTHON */
 
Index: varobj.h
===================================================================
RCS file: /cvs/src/src/gdb/varobj.h,v
retrieving revision 1.27
diff -u -p -r1.27 varobj.h
--- varobj.h	12 Jan 2011 01:23:29 -0000	1.27
+++ varobj.h	11 Mar 2011 15:04:45 -0000
@@ -168,7 +168,7 @@ extern int varobj_editable_p (struct var
 extern int varobj_floating_p (struct varobj *var);
 
 extern void 
-varobj_set_visualizer (struct varobj *var, const char *visualizer);
+  varobj_set_visualizer (struct varobj *var, const char *visualizer);
 
 extern void varobj_enable_pretty_printing (void);
 
Index: python/py-stopevent.h
===================================================================
RCS file: /cvs/src/src/gdb/python/py-stopevent.h,v
retrieving revision 1.1
diff -u -p -r1.1 py-stopevent.h
--- python/py-stopevent.h	5 Feb 2011 05:27:23 -0000	1.1
+++ python/py-stopevent.h	11 Mar 2011 15:04:45 -0000
@@ -29,9 +29,9 @@ extern int emit_stop_event (struct bpsta
                             enum target_signal stop_signal);
 
 extern PyObject *
-create_breakpoint_event_object (PyObject *breakpoint);
+  create_breakpoint_event_object (PyObject *breakpoint);
 
 extern PyObject *
-create_signal_event_object (enum target_signal stop_signal);
+  create_signal_event_object (enum target_signal stop_signal);
 
 #endif /* GDB_PY_STOPEVENT_H */

RE: [RFA] Fix ARI warnings about function with no parameters ( RE: New ARI warning Sat Mar 12 01:53:29 UTC 2011)

[Pierre Muller]

  As Eli agreed on that part,
I checked it in the following.


Pierre Muller
as ARI maintainer

(I appended the wrong patch to
my two emails...)
thus I resend it here.





2011-03-14  Pierre Muller  <muller@ics.u-strasbg.fr>

	Fix ARI warning about functions without parameters that do not
	use (void).
	* breakpoint.c (all_tracepoints): Replace () by (void).
	* f-exp.y (match_string_literal): Ditto.
	(yylex): Ditto.
	* m2-exp.y (yylex): Ditto.
	* mep-tdep.c (current_me_module): Ditto.
	(current_options): Ditto.
	(current_cop_data_bus_width): Ditto.
	(current_cr_names): Ditto.
	(current_cr_is_float): Ditto.
	(current_ccr_names): Ditto.
	* objc-exp.y (yylex): Ditto.
	* p-exp.y (yylex): Ditto.
	* remote.c (send_interrupt_sequence): Ditto.
	* tracepoint.c (current_trace_status): Ditto.
	* python/py-evts.c (gdbpy_initialize_py_events): Ditto.
	* python/py-prettyprint.c (push_dummy_python_frame): Ditto.

Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.550
diff -u -p -r1.550 breakpoint.c
--- breakpoint.c	10 Mar 2011 18:33:59 -0000	1.550
+++ breakpoint.c	11 Mar 2011 15:18:06 -0000
@@ -11952,7 +11952,7 @@ save_tracepoints_command (char *args, in
 /* Create a vector of all tracepoints.  */
 
 VEC(breakpoint_p) *
-all_tracepoints ()
+all_tracepoints (void)
 {
   VEC(breakpoint_p) *tp_vec = 0;
   struct breakpoint *tp;
Index: f-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/f-exp.y,v
retrieving revision 1.36
diff -u -p -r1.36 f-exp.y
--- f-exp.y	7 Jan 2011 19:36:16 -0000	1.36
+++ f-exp.y	11 Mar 2011 15:18:06 -0000
@@ -919,7 +919,7 @@ growbuf_by_size (count)
    a string, it is simply doubled (I.E. 'this''is''one''string') */
 
 static int
-match_string_literal ()
+match_string_literal (void)
 {
   char *tokptr = lexptr;
 
@@ -951,7 +951,7 @@ match_string_literal ()
 /* Read one token, getting characters through lexptr.  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c;
   int namelen;
Index: m2-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/m2-exp.y,v
retrieving revision 1.33
diff -u -p -r1.33 m2-exp.y
--- m2-exp.y	9 Jan 2011 03:20:33 -0000	1.33
+++ m2-exp.y	11 Mar 2011 15:18:06 -0000
@@ -808,7 +808,7 @@ static struct keyword keytab[] =
    compatible  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c;
   int namelen;
Index: mep-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mep-tdep.c,v
retrieving revision 1.29
diff -u -p -r1.29 mep-tdep.c
--- mep-tdep.c	10 Jan 2011 17:14:12 -0000	1.29
+++ mep-tdep.c	11 Mar 2011 15:18:06 -0000
@@ -845,7 +845,7 @@ mep_pseudo_cr_index (int pseudo)
    from the ELF header's e_flags field of the current executable
    file.  */
 static CONFIG_ATTR
-current_me_module ()
+current_me_module (void)
 {
   if (target_has_registers)
     {
@@ -868,7 +868,7 @@ current_me_module ()
    then use the 'module_opt' field we computed when we build the
    gdbarch object for this module.  */
 static unsigned int
-current_options ()
+current_options (void)
 {
   if (target_has_registers)
     {
@@ -885,7 +885,7 @@ current_options ()
 /* Return the width of the current me_module's coprocessor data bus,
    in bits.  This is either 32 or 64.  */
 static int
-current_cop_data_bus_width ()
+current_cop_data_bus_width (void)
 {
   return me_module_cop_data_bus_width (current_me_module ());
 }
@@ -894,7 +894,7 @@ current_cop_data_bus_width ()
 /* Return the keyword table of coprocessor general-purpose register
    names appropriate for the me_module we're dealing with.  */
 static CGEN_KEYWORD *
-current_cr_names ()
+current_cr_names (void)
 {
   const CGEN_HW_ENTRY *hw
     = me_module_register_set (current_me_module (), "h-cr-", HW_H_CR);
@@ -906,7 +906,7 @@ current_cr_names ()
 /* Return non-zero if the coprocessor general-purpose registers are
    floating-point values, zero otherwise.  */
 static int
-current_cr_is_float ()
+current_cr_is_float (void)
 {
   const CGEN_HW_ENTRY *hw
     = me_module_register_set (current_me_module (), "h-cr-", HW_H_CR);
@@ -918,7 +918,7 @@ current_cr_is_float ()
 /* Return the keyword table of coprocessor control register names
    appropriate for the me_module we're dealing with.  */
 static CGEN_KEYWORD *
-current_ccr_names ()
+current_ccr_names (void)
 {
   const CGEN_HW_ENTRY *hw
     = me_module_register_set (current_me_module (), "h-ccr-", HW_H_CCR);
Index: objc-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/objc-exp.y,v
retrieving revision 1.41
diff -u -p -r1.41 objc-exp.y
--- objc-exp.y	10 Jan 2011 20:38:49 -0000	1.41
+++ objc-exp.y	11 Mar 2011 15:18:06 -0000
@@ -1218,7 +1218,7 @@ static const struct token tokentab2[] =
 /* Read one token, getting characters through lexptr.  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c, tokchr;
   int namelen;
Index: p-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/p-exp.y,v
retrieving revision 1.54
diff -u -p -r1.54 p-exp.y
--- p-exp.y	17 Jan 2011 10:34:51 -0000	1.54
+++ p-exp.y	11 Mar 2011 15:18:06 -0000
@@ -1120,7 +1120,7 @@ static int last_was_structop;
 /* Read one token, getting characters through lexptr.  */
 
 static int
-yylex ()
+yylex (void)
 {
   int c;
   int namelen;
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.438
diff -u -p -r1.438 remote.c
--- remote.c	8 Mar 2011 12:46:51 -0000	1.438
+++ remote.c	11 Mar 2011 15:18:07 -0000
@@ -3112,7 +3112,7 @@ struct start_remote_args
 
 /* Send interrupt_sequence to remote target.  */
 static void
-send_interrupt_sequence ()
+send_interrupt_sequence (void)
 {
   if (interrupt_sequence_mode == interrupt_sequence_control_c)
     serial_write (remote_desc, "\x03", 1);
Index: tracepoint.c
===================================================================
RCS file: /cvs/src/src/gdb/tracepoint.c,v
retrieving revision 1.216
diff -u -p -r1.216 tracepoint.c
--- tracepoint.c	10 Mar 2011 18:33:59 -0000	1.216
+++ tracepoint.c	11 Mar 2011 15:18:08 -0000
@@ -218,7 +218,7 @@ char *stop_reason_names[] = {
 };
 
 struct trace_status *
-current_trace_status ()
+current_trace_status (void)
 {
   return &trace_status;
 }
Index: python/py-evts.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-evts.c,v
retrieving revision 1.1
diff -u -p -r1.1 py-evts.c
--- python/py-evts.c	5 Feb 2011 05:27:23 -0000	1.1
+++ python/py-evts.c	11 Mar 2011 15:18:08 -0000
@@ -42,7 +42,7 @@ add_new_registry (eventregistry_object *
 }
 
 void
-gdbpy_initialize_py_events ()
+gdbpy_initialize_py_events (void)
 {
   gdb_py_events.module = Py_InitModule ("events", NULL);
 
Index: python/py-prettyprint.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-prettyprint.c,v
retrieving revision 1.23
diff -u -p -r1.23 py-prettyprint.c
--- python/py-prettyprint.c	1 Mar 2011 21:54:53 -0000	1.23
+++ python/py-prettyprint.c	11 Mar 2011 15:18:08 -0000
@@ -394,7 +394,7 @@ py_restore_tstate (void *p)
 /* Create a dummy PyFrameObject, needed to work around
    a Python-2.4 bug with generators.  */
 static PyObject *
-push_dummy_python_frame ()
+push_dummy_python_frame (void)
 {
   PyObject *empty_string, *null_tuple, *globals;
   PyCodeObject *code;

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Sun, 13 Mar 2011 09:21:35 +0100
> 
>   This is the consequence of the two new ARI rules I added:
> http://sourceware.org/ml/gdb-patches/2011-03/msg00654.html
> 
>   As I just introduced these new rules,
> I felt that it would be cheating to
> use OBVIOUS rule as we normally do to fix 
> a ARI regression...
>   This is why I will submit shortly two patches
> to remove all those new warnings.

The rule to detect "()" without a "void" is fine, but why on Earth do
we need the other rule, about prototypes like this:

  int
  foo (bar);

This is a perfectly valid formatting.  In your patch, you modify long
prototypes like this as follows:

   extern struct hppa_objfile_private *
  -hppa_init_objfile_priv_data (struct objfile *objfile);
  +  hppa_init_objfile_priv_data (struct objfile *objfile);

But that is not a good idea, because if you type TAB in Emacs on the
line with the function name, Emacs will reindent the name to column
zero.  So I expect this rule to annoy us quite a bit, e.g. if someone
reindents a large region.

Can you tell why we need this?

RE: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Eli Zaretskii
> Envoyé : dimanche 13 mars 2011 11:24
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Date: Sun, 13 Mar 2011 09:21:35 +0100
> >
> >   This is the consequence of the two new ARI rules I added:
> > http://sourceware.org/ml/gdb-patches/2011-03/msg00654.html
> >
> >   As I just introduced these new rules,
> > I felt that it would be cheating to
> > use OBVIOUS rule as we normally do to fix
> > a ARI regression...
> >   This is why I will submit shortly two patches
> > to remove all those new warnings.
> 
> The rule to detect "()" without a "void" is fine, but why on Earth do
> we need the other rule, about prototypes like this:
> 
>   int
>   foo (bar);
> 
> This is a perfectly valid formatting.  In your patch, you modify long
> prototypes like this as follows:
> 
>    extern struct hppa_objfile_private *
>   -hppa_init_objfile_priv_data (struct objfile *objfile);
>   +  hppa_init_objfile_priv_data (struct objfile *objfile);
> 
> But that is not a good idea, because if you type TAB in Emacs on the
> line with the function name, Emacs will reindent the name to column
> zero.  So I expect this rule to annoy us quite a bit, e.g. if someone
> reindents a large region.
> 
> Can you tell why we need this?

  See
http://sourceware.org/ml/gdb-patches/2011-03/msg00651.html

  This way you will find only the implementation of function foo_function
using grep:

grep "^foo_function" *

  I really thought that prototypes,
either in header or in C sources should not be found by that
pattern and that it shouls thus either be on a single line,
or be indented to avoid being on first column.

 Notice that the new rule only found a few of these
extern TYPE
long_func_name (with_long_parameters);

  Would it be better to reformat those as
extern TYPE long_func_name 
  (with_long_parameters);
instead of
extern TYPE
  long_func_name (with_long_parameters);

  I have no preference on that matter,
I would really like to avoid getting both the
prototype and the implementation if I do:

grep "^func_name " 

That's the reason of this rule.

  Tell us what you think about the alternate
I propose above and what we should do in your opinion.


Pierre Muller
as ARI maintainer.

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Cc: <gdb-patches@sourceware.org>
> Date: Mon, 14 Mar 2011 09:20:07 +0100
> 
> > The rule to detect "()" without a "void" is fine, but why on Earth do
> > we need the other rule, about prototypes like this:
> > 
> >   int
> >   foo (bar);
> > 
> > This is a perfectly valid formatting.  In your patch, you modify long
> > prototypes like this as follows:
> > 
> >    extern struct hppa_objfile_private *
> >   -hppa_init_objfile_priv_data (struct objfile *objfile);
> >   +  hppa_init_objfile_priv_data (struct objfile *objfile);
> > 
> > But that is not a good idea, because if you type TAB in Emacs on the
> > line with the function name, Emacs will reindent the name to column
> > zero.  So I expect this rule to annoy us quite a bit, e.g. if someone
> > reindents a large region.
> > 
> > Can you tell why we need this?
> 
>   See
> http://sourceware.org/ml/gdb-patches/2011-03/msg00651.html

That was about _definitions_, not about declarations of prototypes.

Anyway, I don't see how is it relevant: that message talks about the
need to put the names of the functions in the beginning of a line (a
long standing GNU coding style practice), exactly the practice which
will according to your change trigger ARI warnings when used with a
prototype.

>   I really thought that prototypes,
> either in header or in C sources should not be found by that
> pattern and that it shouls thus either be on a single line,
> or be indented to avoid being on first column.

Are we adding ARI warnings to help ARI find function implementations
and skip prototypes?  If this is the need, why not look for the
semi-colon at the end of the prototype, which will be absent in
function definitions?

>   Would it be better to reformat those as
> extern TYPE long_func_name 
>   (with_long_parameters);
> instead of
> extern TYPE
>   long_func_name (with_long_parameters);

No, that's even uglier.

> I would really like to avoid getting both the
> prototype and the implementation if I do:
> 
> grep "^func_name " 

Then let's find a smarter way of finding just the implementation.
Forcing some unusual style on our code to help Grep is not a good
idea, IMO.

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pedro Alves]

On Monday 14 March 2011 11:26:40, Eli Zaretskii wrote:
> >   Would it be better to reformat those as
> > extern TYPE long_func_name 
> >   (with_long_parameters);
> > instead of
> > extern TYPE
> >   long_func_name (with_long_parameters);
> 
> No, that's even uglier.
> 

But it's what we do all over.  We do have the rule that
grep "^foofunc" should only match function definitions, not
declarations.  Here in gdbint.texinfo:

"A function declaration should not have its name in column zero.  A
function definition should have its name in column zero."

-- 
Pedro Alves

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Mon, 14 Mar 2011 12:13:43 +0000
> Cc: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> 
> On Monday 14 March 2011 11:26:40, Eli Zaretskii wrote:
> > >   Would it be better to reformat those as
> > > extern TYPE long_func_name 
> > >   (with_long_parameters);
> > > instead of
> > > extern TYPE
> > >   long_func_name (with_long_parameters);
> > 
> > No, that's even uglier.
> > 
> 
> But it's what we do all over.  We do have the rule that
> grep "^foofunc" should only match function definitions, not
> declarations.  Here in gdbint.texinfo:
> 
> "A function declaration should not have its name in column zero.  A
> function definition should have its name in column zero."

What can I say? it's ugly.

RE: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pierre Muller]

> But it's what we do all over.  We do have the rule that
> grep "^foofunc" should only match function definitions, not
> declarations.  Here in gdbint.texinfo:
> 
> "A function declaration should not have its name in column zero.  A
> function definition should have its name in column zero."

  Thank you for finding this out...
This is clearer than what I try to explain to Eli before.

  Eli, do you agree with this statement 
in gdbint.textinfo or should it be modified?

  Would you like to enhance it to specify what to do if
the whole function declaration
TYPE NAME (PARAMS);
doesn't fit into a 80 columns line?

 I am willing to adapt the ARI rule to such recommendations.

Pierre



  

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Mon, 14 Mar 2011 13:34:16 +0100
> 
> > "A function declaration should not have its name in column zero.  A
> > function definition should have its name in column zero."
> 
>   Thank you for finding this out...
> This is clearer than what I try to explain to Eli before.
> 
>   Eli, do you agree with this statement 
> in gdbint.textinfo or should it be modified?

That sentence says what one should _not_ do.  The issue in this thread
is what to do instead.

>   Would you like to enhance it to specify what to do if
> the whole function declaration
> TYPE NAME (PARAMS);
> doesn't fit into a 80 columns line?
> 
>  I am willing to adapt the ARI rule to such recommendations.

I suggested how to format that case.  If that suggestion is accepted,
I will change gdbint.texinfo accordingly.

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Mon, 14 Mar 2011 12:13:43 +0000
> Cc: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> 
> "A function declaration should not have its name in column zero.  A
> function definition should have its name in column zero."

At the very least, please reformat the prototypes like this:

extern whatever_type foo (type1_t,
       		     	  type2_t, const char **, foobar_t);

not like Pierre originally suggested.

That is, let the left paren and at least one argument be on the same
line as the function name.

RE: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pierre Muller]

> -----Message d'origine-----
> De : Eli Zaretskii [mailto:eliz@gnu.org]
> Envoyé : lundi 14 mars 2011 13:35
> À : Pedro Alves
> Cc : gdb-patches@sourceware.org; pierre.muller@ics-cnrs.unistra.fr
> Objet : Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011
> 
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Mon, 14 Mar 2011 12:13:43 +0000
> > Cc: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> >
> > "A function declaration should not have its name in column zero.  A
> >  function definition should have its name in column zero."

> 
> What can I say? it's ugly.

  Eli, the only C coding standard I was ever confronted with 
is GDB coding standards.
  And this is probably one of the first rules
that I understood.
  I find this rule quite useful, as it allows
easy tracking of function implementation.

> 
> At the very least, please reformat the prototypes like this:
> 
> extern whatever_type foo (type1_t,
>        		     	  type2_t, const char **, foobar_t);
> 
> not like Pierre originally suggested.
> 
> That is, let the left paren and at least one argument be on the same
> line as the function name.

  I agree with the principle, but
it is not always possible:

What should we do with this:
$ grep -n -C 3 "^[a-z][a-z0-9_]*[[:space:]]*(.*)" *.h
linux-nat.h-147-/* Create a generic GNU/Linux target using traditional
linux-nat.h-148-   ptrace register access.  */
linux-nat.h-149-struct target_ops *
linux-nat.h:150:linux_trad_target (CORE_ADDR (*register_u_offset)(struct
gdbarch *, int, int));
linux-nat.h-151-
linux-nat.h-152-/* Register the customized GNU/Linux target.  This should be
used
linux-nat.h-153-   instead of calling add_target directly.  */

 OK, I must admit that I cheated, because that did not even appear in the
ARI list,
while it should.
  It should be in the list because it is one of the
functions declarations that are in first column,
it does not appear because I oversimplified the rule
using 
/^[a-z][a-z0-9_]*[[:space:]]*\((|[^*][^()]*)\)[[:space:]]*[^ \t]+/ 
awk pattern to avoid getting all function variables.
  If someone can suggest a more complete pattern that would also
grab the above without matching 
int (*test_var_function (int, int));
I would be grateful.

Pierre

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Cc: <gdb-patches@sourceware.org>
> Date: Mon, 14 Mar 2011 13:49:39 +0100
> 
> linux-nat.h-147-/* Create a generic GNU/Linux target using traditional
> linux-nat.h-148-   ptrace register access.  */
> linux-nat.h-149-struct target_ops *
> linux-nat.h:150:linux_trad_target (CORE_ADDR (*register_u_offset)(struct
> gdbarch *, int, int));

Either

struct target_ops *linux_trad_target (CORE_ADDR (*register_u_offset)(struct gdbarch *,
                                                                     int, int));

or even

struct target_ops *linux_trad_target (CORE_ADDR (*register_u_offset)(struct gdbarch *, int, int));

IOW, such marginal examples are not interesting (one should use a
typedef for that function argument, anyway, to make the prototype
legible).

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pedro Alves]

On Monday 14 March 2011 12:34:49, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Mon, 14 Mar 2011 12:13:43 +0000
> > Cc: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > 
> > "A function declaration should not have its name in column zero.  A
> > function definition should have its name in column zero."
> 
> At the very least, please reformat the prototypes like this:
> 
> extern whatever_type foo (type1_t,
>        		     	  type2_t, const char **, foobar_t);
> 
> not like Pierre originally suggested.
> 
> That is, let the left paren and at least one argument be on the same
> line as the function name.

I'm fine with your suggestion, and in fact it's my preference
as well.  However, there _are_ cases where you just can't do that,
because the return type + function name + parameter end up being
too long for a single line.  It's even easier to happen when you need
to spell out the parameter name, not just the type (to refer
to in the describing comment).

-- 
Pedro Alves

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Mon, 14 Mar 2011 12:51:31 +0000
> Cc: gdb-patches@sourceware.org,
>  pierre.muller@ics-cnrs.unistra.fr
> 
> > extern whatever_type foo (type1_t,
> >        		     	  type2_t, const char **, foobar_t);
> > 
> > not like Pierre originally suggested.
> > 
> > That is, let the left paren and at least one argument be on the same
> > line as the function name.
> 
> I'm fine with your suggestion, and in fact it's my preference
> as well.  However, there _are_ cases where you just can't do that,
> because the return type + function name + parameter end up being
> too long for a single line.

What's wrong with leaving a single long line in such cases?  They are
supposed to be very rare (if typedefs are used for complex function
arguments).

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pedro Alves]

On Monday 14 March 2011 13:06:08, Eli Zaretskii wrote:
> > I'm fine with your suggestion, and in fact it's my preference
> > as well.  However, there are cases where you just can't do that,
> > because the return type + function name + parameter end up being
> > too long for a single line.
> 
> What's wrong with leaving a single long line in such cases?  They are
> supposed to be very rare (if typedefs are used for complex function
> arguments).

If we have a rule to follow, we should follow it everywhere.
And they are not very rare; we have quite a few cases.  The most
prominent styles are:

/* Find a particular location expression from a location list.  */
const gdb_byte *dwarf2_find_location_expression
  (struct dwarf2_loclist_baton *baton,
   size_t *locexpr_length,
   CORE_ADDR pc);

/* Find an inferior bound to PSPACE.  */
extern struct inferior *
  find_inferior_for_program_space (struct program_space *pspace);

-- 
Pedro Alves

RE: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Pierre Muller]

> > I'm fine with your suggestion, and in fact it's my preference
> > as well.  However, there _are_ cases where you just can't do that,
> > because the return type + function name + parameter end up being
> > too long for a single line.
> 
> What's wrong with leaving a single long line in such cases?  They are
> supposed to be very rare (if typedefs are used for complex function
> arguments).

  Take for instance a look at hppa-tdep.h:
my patch changes
<<<hppa-tdep.h>>>>
extern struct hppa_objfile_private *
hppa_init_objfile_priv_data (struct objfile *objfile);
<<<hppa-tdep.h>>>>
into:

<<<hppa-tdep.h>>>>
extern struct hppa_objfile_private *
  hppa_init_objfile_priv_data (struct objfile *objfile);
<<<hppa-tdep.h>>>>

Your suggestion would lead to:
<<<hppa-tdep.h>>>>
extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct
objfile *objfile);
<<<hppa-tdep.h>>>>

on a single line (might have been corrupted by my mailer...)
91 column wide...

but if you look at the rest of the hppa-tdep.h file, you will find:

<<<hppa-tdep.h>>>>
extern struct value *
  hppa_frame_prev_register_helper (struct frame_info *this_frame,
                                   struct trad_frame_saved_reg *saved_regs,
                                   int regnum);

extern CORE_ADDR hppa_read_pc (struct regcache *regcache);
extern void hppa_write_pc (struct regcache *regcache, CORE_ADDR pc);
extern CORE_ADDR hppa_unwind_pc (struct gdbarch *gdbarch,
                                 struct frame_info *next_frame);

extern struct minimal_symbol *
  hppa_lookup_stub_minimal_symbol (const char *name,
                                   enum unwind_stub_types stub_type);

extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct
objfile
 *objfile);

extern int hppa_in_solib_call_trampoline (struct gdbarch *gdbarch,
                                          CORE_ADDR pc, char *name);
extern CORE_ADDR hppa_skip_trampoline_code (struct frame_info *, CORE_ADDR
pc);
<<<hppa-tdep.h>>>>

  So you can see that the ugly formatting, I proposed is already
used twice.
  I found 37 occurrences listed below,
should we considered those as badly formatted?


Pierre


$ grep -E "^  [a-z][a-zA-Z_0-9]* *\([^*][^()]*(\);|,)$" *.h
ada-lang.h:  ada_decode_exception_location (char *args, char **addr_string,
ada-lang.h:  ada_decode_assert_location (char *args, char **addr_string,
alphabsd-tdep.h:  alphanbsd_regset_from_core_section (struct gdbarch
*gdbarch,
arch-utils.h:  simple_displaced_step_copy_insn (struct gdbarch *gdbarch,
arch-utils.h:  simple_displaced_step_free_closure (struct gdbarch *gdbarch,
arch-utils.h:  default_displaced_step_hw_singlestep (struct gdbarch *,
arm-tdep.h:  arm_process_displaced_insn (struct gdbarch *gdbarch, CORE_ADDR
from,
arm-tdep.h:  arm_displaced_init_closure (struct gdbarch *gdbarch, CORE_ADDR
from,
arm-tdep.h:  displaced_read_reg (struct regcache *regs, struct
displaced_step_closure *dsc,
arm-tdep.h:  displaced_write_reg (struct regcache *regs,
arm-tdep.h:  arm_displaced_step_copy_insn (struct gdbarch *, CORE_ADDR,
CORE_ADDR,
arm-tdep.h:  armbsd_regset_from_core_section (struct gdbarch *gdbarch,
defs.h:  make_cleanup_ui_out_redirect_pop (struct ui_out *uiout);
defs.h:  make_cleanup_restore_ui_file (struct ui_file **variable);
defs.h:  set_batch_flag_and_make_cleanup_restore_page_info (void);
dwarf2-frame.h:  dwarf2_frame_set_signal_frame_p (struct gdbarch *gdbarch,
dwarf2-frame.h:  dwarf2_frame_set_adjust_regnum (struct gdbarch *gdbarch,
dwarf2-frame.h:  dwarf2_frame_base_sniffer (struct frame_info *this_frame);
event-loop.h:  create_async_event_handler (async_event_handler_func *proc,
event-loop.h:  delete_async_event_handler (struct async_event_handler
**handler_ptr);
hppa-tdep.h:  hppa_frame_prev_register_helper (struct frame_info
*this_frame,
hppa-tdep.h:  hppa_lookup_stub_minimal_symbol (const char *name,
i386-tdep.h:  i386_regset_from_core_section (struct gdbarch *gdbarch,
inferior.h:  get_infcall_suspend_state_regcache (struct
infcall_suspend_state *);
inferior.h:  get_displaced_step_closure_by_addr (CORE_ADDR addr);
inferior.h:  find_inferior_for_program_space (struct program_space *pspace);
p-lang.h:  is_pascal_string_type (struct type *, int *, int *, int *,
p-lang.h:  pascal_type_print_base (struct type *, struct ui_file *, int,
int);
p-lang.h:  pascal_type_print_varspec_prefix (struct type *, struct ui_file
*, int, int);
sparc-tdep.h:  sparc_frame_cache (struct frame_info *this_frame, void
**this_cache);
sparc-tdep.h:  sparc32_frame_cache (struct frame_info *this_frame, void
**this_cache);
sparc-tdep.h:  sparc32nbsd_sigcontext_saved_regs (struct frame_info
*next_frame);
sparc64-tdep.h:  sparc64nbsd_sigcontext_saved_regs (CORE_ADDR
sigcontext_addr,
symfile.h:  build_section_addr_info_from_objfile (const struct objfile
*objfile);
value.h:  value_contents_for_printing_const (const struct value *value);
value.h:  create_internalvar_type_lazy (char *name, internalvar_make_value
fun);
varobj.h:  varobj_set_visualizer (struct varobj *var, const char
*visualizer);
  

Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011

[Mark Kettenis]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Mon, 14 Mar 2011 15:20:48 +0100
> 
> > > I'm fine with your suggestion, and in fact it's my preference
> > > as well.  However, there _are_ cases where you just can't do that,
> > > because the return type + function name + parameter end up being
> > > too long for a single line.
> > 
> > What's wrong with leaving a single long line in such cases?  They are
> > supposed to be very rare (if typedefs are used for complex function
> > arguments).
> 
>   Take for instance a look at hppa-tdep.h:
> my patch changes
> <<<hppa-tdep.h>>>>
> extern struct hppa_objfile_private *
> hppa_init_objfile_priv_data (struct objfile *objfile);
> <<<hppa-tdep.h>>>>
> into:
> 
> <<<hppa-tdep.h>>>>
> extern struct hppa_objfile_private *
>   hppa_init_objfile_priv_data (struct objfile *objfile);
> <<<hppa-tdep.h>>>>
> 
> Your suggestion would lead to:
> <<<hppa-tdep.h>>>>
> extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct
> objfile *objfile);
> <<<hppa-tdep.h>>>>
> 
> on a single line (might have been corrupted by my mailer...)
> 91 column wide...
> 
> but if you look at the rest of the hppa-tdep.h file, you will find:
> 
> <<<hppa-tdep.h>>>>
> extern struct value *
>   hppa_frame_prev_register_helper (struct frame_info *this_frame,
>                                    struct trad_frame_saved_reg *saved_regs,
>                                    int regnum);
> 
> extern CORE_ADDR hppa_read_pc (struct regcache *regcache);
> extern void hppa_write_pc (struct regcache *regcache, CORE_ADDR pc);
> extern CORE_ADDR hppa_unwind_pc (struct gdbarch *gdbarch,
>                                  struct frame_info *next_frame);
> 
> extern struct minimal_symbol *
>   hppa_lookup_stub_minimal_symbol (const char *name,
>                                    enum unwind_stub_types stub_type);
> 
> extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct
> objfile
>  *objfile);
> 
> extern int hppa_in_solib_call_trampoline (struct gdbarch *gdbarch,
>                                           CORE_ADDR pc, char *name);
> extern CORE_ADDR hppa_skip_trampoline_code (struct frame_info *, CORE_ADDR
> pc);
> <<<hppa-tdep.h>>>>
> 
>   So you can see that the ugly formatting, I proposed is already
> used twice.
>   I found 37 occurrences listed below,
> should we considered those as badly formatted?

Indenting the function name with two spaces is what we traditionally
did for long prototypes.  I think it is a perfectly fine solution for
the "problem" at hand.

Re: [RFA] Fix ARI warning about function call in first column

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre> This second patch fixes:
>> gdb/hppa-tdep.h:244: code: function call in first column: Function name in
Pierre> first column should be restricted to function implementation
Pierre> gdb/hppa-tdep.h:244:hppa_init_objfile_priv_data (struct objfile *objfile);
Pierre> and other occurrences of same new warning.

This is ok.  Thanks for doing this.

Tom

[RFA-v2] Fix ARI warning about function call in first column

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : lundi 14 mars 2011 15:49
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFA] Fix ARI warning about function call in first column
> 
> >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
> writes:
> 
> Pierre> This second patch fixes:
> >> gdb/hppa-tdep.h:244: code: function call in first column: Function
> name in
> Pierre> first column should be restricted to function implementation
> Pierre> gdb/hppa-tdep.h:244:hppa_init_objfile_priv_data (struct objfile
> *objfile);
> Pierre> and other occurrences of same new warning.
> 
> This is ok.  Thanks for doing this.

  As Eli had some concerns about that part,
I tried to change my patch so that it does add new
function declarations split in between return type and 
function name.
  
  Eli, this still leaves us with two 
cases for which we either have
TYPE
  NAME (PARAMS);
or
TYPE NAME (PARAMS);
with a single line that exceeds 80 columns.

  I didn't really understand your comment about
automatic indenting by emacs because I never used emacs :(
As the 37 already existing cases suggest,
this couldn't have worked correctly even before my patch, no?

  If you really prefer and others also agree,
I can submit a variant with single lines...

Pierre



2011-03-14  Pierre Muller  <muller@ics.u-strasbg.fr>

	Fix ARI warning about function names in first column.
	Put prototype declaration on same line as return type.
	* objc-exp.y: Ditto.
	* p-exp.y: Ditto.
	For long function names, indent prototype declarations to avoid
	function name in first column.
	* hppa-tdep.h: Ditto.
	* inferior.h: Ditto.
	* solib-pa64.c: Ditto.
	* varobj.c: Ditto.
	* varobj.h: Ditto.
	* python/py-stopevent.h: Ditto.


Index: hppa-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.h,v
retrieving revision 1.41
diff -u -p -r1.41 hppa-tdep.h
--- hppa-tdep.h	9 Jan 2011 03:08:55 -0000	1.41
+++ hppa-tdep.h	14 Mar 2011 15:57:30 -0000
@@ -241,7 +241,7 @@ extern struct minimal_symbol *
                                    enum unwind_stub_types stub_type);
 
 extern struct hppa_objfile_private *
-hppa_init_objfile_priv_data (struct objfile *objfile);
+  hppa_init_objfile_priv_data (struct objfile *objfile);
 
 extern int hppa_in_solib_call_trampoline (struct gdbarch *gdbarch,
 					  CORE_ADDR pc, char *name);
Index: inferior.h
===================================================================
RCS file: /cvs/src/src/gdb/inferior.h,v
retrieving revision 1.152
diff -u -p -r1.152 inferior.h
--- inferior.h	26 Feb 2011 02:07:08 -0000	1.152
+++ inferior.h	14 Mar 2011 15:57:30 -0000
@@ -367,7 +367,7 @@ void displaced_step_dump_bytes (struct u
                                 const gdb_byte *buf, size_t len);
 
 struct displaced_step_closure*
-get_displaced_step_closure_by_addr (CORE_ADDR addr);
+  get_displaced_step_closure_by_addr (CORE_ADDR addr);
 

 /* Possible values for gdbarch_call_dummy_location.  */
 #define ON_STACK 1
Index: objc-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/objc-exp.y,v
retrieving revision 1.42
diff -u -p -r1.42 objc-exp.y
--- objc-exp.y	14 Mar 2011 15:43:50 -0000	1.42
+++ objc-exp.y	14 Mar 2011 15:57:30 -0000
@@ -107,14 +107,11 @@
 #define	YYDEBUG	0		/* Default to no yydebug support.
*/
 #endif
 
-int
-yyparse (void);
+int yyparse (void);
 
-static int
-yylex (void);
+static int yylex (void);
 
-void
-yyerror (char *);
+void yyerror (char *);
 
 %}
 
@@ -150,8 +147,7 @@ yyerror (char *);
 
 %{
 /* YYSTYPE gets defined by %union.  */
-static int
-parse_number (char *, int, int, YYSTYPE *);
+static int parse_number (char *, int, int, YYSTYPE *);
 %}
 
 %type <voidval> exp exp1 type_exp start variable qualified_name lcurly
Index: p-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/p-exp.y,v
retrieving revision 1.55
diff -u -p -r1.55 p-exp.y
--- p-exp.y	14 Mar 2011 15:43:50 -0000	1.55
+++ p-exp.y	14 Mar 2011 15:57:30 -0000
@@ -117,8 +117,7 @@ int yyparse (void);
 
 static int yylex (void);
 
-void
-yyerror (char *);
+void yyerror (char *);
 
 static char * uptok (char *, int);
 %}
@@ -154,8 +153,7 @@ static char * uptok (char *, int);
 
 %{
 /* YYSTYPE gets defined by %union */
-static int
-parse_number (char *, int, int, YYSTYPE *);
+static int parse_number (char *, int, int, YYSTYPE *);
 
 static struct type *current_type;
 static struct internalvar *intvar;
Index: solib-pa64.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-pa64.c,v
retrieving revision 1.29
diff -u -p -r1.29 solib-pa64.c
--- solib-pa64.c	11 Jan 2011 21:53:24 -0000	1.29
+++ solib-pa64.c	14 Mar 2011 15:57:30 -0000
@@ -76,8 +76,8 @@ dld_cache_t;
 
 static dld_cache_t dld_cache;
 
-static int
-read_dynamic_info (asection *dyninfo_sect, dld_cache_t *dld_cache_p);
+static int read_dynamic_info (asection *dyninfo_sect,
+			      dld_cache_t *dld_cache_p);
 
 static void
 pa64_relocate_section_addresses (struct so_list *so,
Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.172
diff -u -p -r1.172 varobj.c
--- varobj.c	5 Mar 2011 22:02:47 -0000	1.172
+++ varobj.c	14 Mar 2011 15:57:31 -0000
@@ -296,8 +296,9 @@ static int is_root_p (struct varobj *var
 
 #if HAVE_PYTHON
 
-static struct varobj *
-varobj_add_child (struct varobj *var, const char *name, struct value
*value);
+static struct varobj * varobj_add_child (struct varobj *var,
+					 const char *name,
+					 struct value *value);
 
 #endif /* HAVE_PYTHON */
 
Index: varobj.h
===================================================================
RCS file: /cvs/src/src/gdb/varobj.h,v
retrieving revision 1.27
diff -u -p -r1.27 varobj.h
--- varobj.h	12 Jan 2011 01:23:29 -0000	1.27
+++ varobj.h	14 Mar 2011 15:57:31 -0000
@@ -167,8 +167,8 @@ extern int varobj_editable_p (struct var
 
 extern int varobj_floating_p (struct varobj *var);
 
-extern void 
-varobj_set_visualizer (struct varobj *var, const char *visualizer);
+extern void varobj_set_visualizer (struct varobj *var,
+				   const char *visualizer);
 
 extern void varobj_enable_pretty_printing (void);
 
Index: python/py-stopevent.h
===================================================================
RCS file: /cvs/src/src/gdb/python/py-stopevent.h,v
retrieving revision 1.1
diff -u -p -r1.1 py-stopevent.h
--- python/py-stopevent.h	5 Feb 2011 05:27:23 -0000	1.1
+++ python/py-stopevent.h	14 Mar 2011 15:57:31 -0000
@@ -28,10 +28,8 @@ extern void stop_evpy_dealloc (PyObject 
 extern int emit_stop_event (struct bpstats *bs,
                             enum target_signal stop_signal);
 
-extern PyObject *
-create_breakpoint_event_object (PyObject *breakpoint);
+extern PyObject * create_breakpoint_event_object (PyObject *breakpoint);
 
-extern PyObject *
-create_signal_event_object (enum target_signal stop_signal);
+extern PyObject * create_signal_event_object (enum target_signal
stop_signal);
 
 #endif /* GDB_PY_STOPEVENT_H */

Re: [RFA-v2] Fix ARI warning about function call in first column

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre>   As Eli had some concerns about that part,
Pierre> I tried to change my patch so that it does add new
Pierre> function declarations split in between return type and 
Pierre> function name.
  
If you want, you can commit the obviously ok ones in the meantime.
Nearly all of your patch seems uncontroversial.

Pierre> -extern PyObject *
Pierre> -create_breakpoint_event_object (PyObject *breakpoint);
Pierre> +extern PyObject * create_breakpoint_event_object (PyObject *breakpoint);
 
Pierre> -extern PyObject *
Pierre> -create_signal_event_object (enum target_signal stop_signal);
Pierre> +extern PyObject * create_signal_event_object (enum target_signal
Pierre> stop_signal);
 
No space after the "*" in these two.

Tom

Re: [RFA-v2] Fix ARI warning about function call in first column

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Cc: <gdb-patches@sourceware.org>
> Date: Mon, 14 Mar 2011 17:03:16 +0100
> 
>   Eli, this still leaves us with two 
> cases for which we either have
> TYPE
>   NAME (PARAMS);
> or
> TYPE NAME (PARAMS);
> with a single line that exceeds 80 columns.

I see no problem with long lines, if there are no better alternatives.
I generally dislike tools that raise warnings for perfectly valid and
readable code, and I don't think we must every follow minor stylistic
rule when that rule gives sub-optimal results.

But it sounds like I'm the only one (again).  So I give up: do
whatever you and others think is right, and I will crawl back under my
rock.


>   I didn't really understand your comment about
> automatic indenting by emacs because I never used emacs :(

In Emacs, hitting the TAB key anywhere on a line of code reindents
this line according to the current setting of the coding style.  The
default coding style is, not surprisingly, the GNU coding style
described in standards.texi.

So, when you hit TAB in a C source file on the second of the two lines
that say

TYPE
  NAME (PARAMS);

Emacs reindents it like this:

TYPE
NAME (PARAMS);

You can also re-indent a whole region of source in Emacs, by marking
the region and pressing TAB.  This is a very convenient way of
reformatting a large portion of code according to GNU standards (which
mostly happen to be GDB standards as well).  When you re-indent a
large region like that, it is easy to undo the kind of formatting you
want to enforce, shown above, because you will not generally go back
and examine each line of the reformatted region -- you trust Emacs to
DTRT.

The  net  result  will  be,   I  fear,  that  such  reformatting  will
inadvertently  undo the  indentation  of prototypes,  and trigger  ARI
warnings for no good reason.

I hope I made myself clear this time.

RE: [RFA-v2] Fix ARI warning about function call in first column

[Pierre Muller]

> -----Message d'origine-----
> De : Eli Zaretskii [mailto:eliz@gnu.org]
> Envoyé : lundi 14 mars 2011 17:46
> À : Pierre Muller
> Cc : tromey@redhat.com; gdb-patches@sourceware.org
> Objet : Re: [RFA-v2] Fix ARI warning about function call in first
> column
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Cc: <gdb-patches@sourceware.org>
> > Date: Mon, 14 Mar 2011 17:03:16 +0100
> >
> >   Eli, this still leaves us with two
> > cases for which we either have
> > TYPE
> >   NAME (PARAMS);
> > or
> > TYPE NAME (PARAMS);
> > with a single line that exceeds 80 columns.
> 
> I see no problem with long lines, if there are no better alternatives.
> I generally dislike tools that raise warnings for perfectly valid and
> readable code, and I don't think we must every follow minor stylistic
> rule when that rule gives sub-optimal results.
> 
> But it sounds like I'm the only one (again).  So I give up: do
> whatever you and others think is right, and I will crawl back under my
> rock.

  Don't do it, I finally committed something that should suit
you as well...


 
> >   I didn't really understand your comment about
> > automatic indenting by emacs because I never used emacs :(
> 
> In Emacs, hitting the TAB key anywhere on a line of code reindents
> this line according to the current setting of the coding style.  The
> default coding style is, not surprisingly, the GNU coding style
> described in standards.texi.
> 
> So, when you hit TAB in a C source file on the second of the two lines
> that say
> 
> TYPE
>   NAME (PARAMS);
> 
> Emacs reindents it like this:
> 
> TYPE
> NAME (PARAMS);
> 
> You can also re-indent a whole region of source in Emacs, by marking
> the region and pressing TAB.  This is a very convenient way of
> reformatting a large portion of code according to GNU standards (which
> mostly happen to be GDB standards as well).  When you re-indent a
> large region like that, it is easy to undo the kind of formatting you
> want to enforce, shown above, because you will not generally go back
> and examine each line of the reformatted region -- you trust Emacs to
> DTRT.
> 
> The  net  result  will  be,   I  fear,  that  such  reformatting  will
> inadvertently  undo the  indentation  of prototypes,  and trigger  ARI
> warnings for no good reason.
> 
> I hope I made myself clear this time.

  Thanks for the explanation.

  Here is what I finally checked in,
it does avoid indented lone function names.

  Personally, I would have done it like this:
TYPE FUNC_NAME (
  PARAMS);
or
TYPE FUNC_NAME (
  PARAM1,
  PARAMS);

but this is another problem.

  This should remove ARI warnings, and
more importantly allow for easy finding of
function implementation (which was my reason
of adding that ARI rule).

  I hope everyone is OK with this.
I think that we do have lots of other occurrences 
of lines longer than 80 cols anyhow...

Pierre


2011-03-14  Pierre Muller  <muller@ics.u-strasbg.fr>

	Fix ARI warning about function names in first column.
	Put prototype declaration on same line as return type.
	* objc-exp.y: Ditto.
	* p-exp.y: Ditto.
	* python/py-stopevent.h: Ditto.
	For long function names, split parameters to
	allow function name on same line as return type.
	* solib-pa64.c: Ditto.
	* varobj.c: Ditto.
	* varobj.h: Ditto.
	For long function declaration, use single line.
	* hppa-tdep.h: Ditto.
	* inferior.h: Ditto.	



Index: objc-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/objc-exp.y,v
retrieving revision 1.42
diff -u -p -r1.42 objc-exp.y
--- objc-exp.y	14 Mar 2011 15:43:50 -0000	1.42
+++ objc-exp.y	14 Mar 2011 16:42:05 -0000
@@ -107,14 +107,11 @@
 #define	YYDEBUG	0		/* Default to no yydebug support.
*/
 #endif
 
-int
-yyparse (void);
+int yyparse (void);
 
-static int
-yylex (void);
+static int yylex (void);
 
-void
-yyerror (char *);
+void yyerror (char *);
 
 %}
 
@@ -150,8 +147,7 @@ yyerror (char *);
 
 %{
 /* YYSTYPE gets defined by %union.  */
-static int
-parse_number (char *, int, int, YYSTYPE *);
+static int parse_number (char *, int, int, YYSTYPE *);
 %}
 
 %type <voidval> exp exp1 type_exp start variable qualified_name lcurly
Index: p-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/p-exp.y,v
retrieving revision 1.55
diff -u -p -r1.55 p-exp.y
--- p-exp.y	14 Mar 2011 15:43:50 -0000	1.55
+++ p-exp.y	14 Mar 2011 16:42:05 -0000
@@ -117,8 +117,7 @@ int yyparse (void);
 
 static int yylex (void);
 
-void
-yyerror (char *);
+void yyerror (char *);
 
 static char * uptok (char *, int);
 %}
@@ -154,8 +153,7 @@ static char * uptok (char *, int);
 
 %{
 /* YYSTYPE gets defined by %union */
-static int
-parse_number (char *, int, int, YYSTYPE *);
+static int parse_number (char *, int, int, YYSTYPE *);
 
 static struct type *current_type;
 static struct internalvar *intvar;
Index: solib-pa64.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-pa64.c,v
retrieving revision 1.29
diff -u -p -r1.29 solib-pa64.c
--- solib-pa64.c	11 Jan 2011 21:53:24 -0000	1.29
+++ solib-pa64.c	14 Mar 2011 16:42:05 -0000
@@ -76,8 +76,8 @@ dld_cache_t;
 
 static dld_cache_t dld_cache;
 
-static int
-read_dynamic_info (asection *dyninfo_sect, dld_cache_t *dld_cache_p);
+static int read_dynamic_info (asection *dyninfo_sect,
+			      dld_cache_t *dld_cache_p);
 
 static void
 pa64_relocate_section_addresses (struct so_list *so,
Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.172
diff -u -p -r1.172 varobj.c
--- varobj.c	5 Mar 2011 22:02:47 -0000	1.172
+++ varobj.c	14 Mar 2011 16:42:06 -0000
@@ -296,8 +296,9 @@ static int is_root_p (struct varobj *var
 
 #if HAVE_PYTHON
 
-static struct varobj *
-varobj_add_child (struct varobj *var, const char *name, struct value
*value);
+static struct varobj * varobj_add_child (struct varobj *var,
+					 const char *name,
+					 struct value *value);
 
 #endif /* HAVE_PYTHON */
 
Index: varobj.h
===================================================================
RCS file: /cvs/src/src/gdb/varobj.h,v
retrieving revision 1.27
diff -u -p -r1.27 varobj.h
--- varobj.h	12 Jan 2011 01:23:29 -0000	1.27
+++ varobj.h	14 Mar 2011 16:42:06 -0000
@@ -167,8 +167,8 @@ extern int varobj_editable_p (struct var
 
 extern int varobj_floating_p (struct varobj *var);
 
-extern void 
-varobj_set_visualizer (struct varobj *var, const char *visualizer);
+extern void varobj_set_visualizer (struct varobj *var,
+				   const char *visualizer);
 
 extern void varobj_enable_pretty_printing (void);
 
Index: python/py-stopevent.h
===================================================================
RCS file: /cvs/src/src/gdb/python/py-stopevent.h,v
retrieving revision 1.1
diff -u -p -r1.1 py-stopevent.h
--- python/py-stopevent.h	5 Feb 2011 05:27:23 -0000	1.1
+++ python/py-stopevent.h	14 Mar 2011 16:42:06 -0000
@@ -28,10 +28,8 @@ extern void stop_evpy_dealloc (PyObject 
 extern int emit_stop_event (struct bpstats *bs,
                             enum target_signal stop_signal);
 
-extern PyObject *
-create_breakpoint_event_object (PyObject *breakpoint);
+extern PyObject *create_breakpoint_event_object (PyObject *breakpoint);
 
-extern PyObject *
-create_signal_event_object (enum target_signal stop_signal);
+extern PyObject *create_signal_event_object (enum target_signal
stop_signal);
 
 #endif /* GDB_PY_STOPEVENT_H */
Index: hppa-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.h,v
retrieving revision 1.41
diff -u -p -r1.41 hppa-tdep.h
--- hppa-tdep.h	9 Jan 2011 03:08:55 -0000	1.41
+++ hppa-tdep.h	14 Mar 2011 16:52:16 -0000
@@ -240,8 +240,7 @@ extern struct minimal_symbol *
   hppa_lookup_stub_minimal_symbol (const char *name,
                                    enum unwind_stub_types stub_type);
 
-extern struct hppa_objfile_private *
-hppa_init_objfile_priv_data (struct objfile *objfile);
+extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct
objfile *objfile);
 
 extern int hppa_in_solib_call_trampoline (struct gdbarch *gdbarch,
 					  CORE_ADDR pc, char *name);
Index: inferior.h
===================================================================
RCS file: /cvs/src/src/gdb/inferior.h,v
retrieving revision 1.152
diff -u -p -r1.152 inferior.h
--- inferior.h	26 Feb 2011 02:07:08 -0000	1.152
+++ inferior.h	14 Mar 2011 16:52:16 -0000
@@ -366,8 +366,7 @@ extern int debug_displaced;
 void displaced_step_dump_bytes (struct ui_file *file,
                                 const gdb_byte *buf, size_t len);
 
-struct displaced_step_closure*
-get_displaced_step_closure_by_addr (CORE_ADDR addr);
+struct displaced_step_closure* get_displaced_step_closure_by_addr
(CORE_ADDR addr);
 

 /* Possible values for gdbarch_call_dummy_location.  */
 #define ON_STACK 1

Re: [RFA-v2] Fix ARI warning about function call in first column

[Tom Tromey]

Eli> I see no problem with long lines, if there are no better alternatives.

I agree.  Sometimes there really is no good answer and you just have to
pick the least worst.

Pierre>   I hope everyone is OK with this.
Pierre> I think that we do have lots of other occurrences 
Pierre> of lines longer than 80 cols anyhow...

It is fine.

Pierre> +static struct varobj * varobj_add_child (struct varobj *var,
Pierre> +					 const char *name,
Pierre> +					 struct value *value);

Extra space after the "*".

Pierre> +extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct

Likewise.

Pierre> +struct displaced_step_closure* get_displaced_step_closure_by_addr

Space is on the wrong side of the "*"; I know you didn't cause this but
if you are fixing the indentation anyway...

Tom

[RFA] Fix formatting in [RFA-v2] Fix ARI warning about function call in first column

[Pierre Muller]

 
> Pierre> +static struct varobj * varobj_add_child (struct varobj *var,
> Pierre> +					 const char *name,
> Pierre> +					 struct value *value);
> 
> Extra space after the "*".
> 
> Pierre> +extern struct hppa_objfile_private *
> hppa_init_objfile_priv_data (struct
> 
> Likewise.
> 
> Pierre> +struct displaced_step_closure*
> get_displaced_step_closure_by_addr
> 
> Space is on the wrong side of the "*"; I know you didn't cause this but
> if you are fixing the indentation anyway...
> 
> Tom

  Is this OK like below?

 Or should I still add the function declarations
on which the change is applied (which I did not
add in my previous ChangeLog entry).

Pierre

ChangeLog entry:

2011-03-15  Pierre Muller  <muller@ics.u-strasbg.fr>

	Fix formatting of functions returning a pointer in previous commit.
	* varobj.c: Ditto.
	* hppa-tdep.h: Ditto.
	* inferior.h: Ditto.

Index: hppa-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.h,v
retrieving revision 1.42
diff -r1.42 hppa-tdep.h
243c243
< extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct
objfile *objfile);
---
> extern struct hppa_objfile_private *hppa_init_objfile_priv_data (struct
objfile *objfile);
Index: inferior.h
===================================================================
RCS file: /cvs/src/src/gdb/inferior.h,v
retrieving revision 1.153
diff -r1.153 inferior.h
369c369
< struct displaced_step_closure* get_displaced_step_closure_by_addr
(CORE_ADDR addr);
---
> struct displaced_step_closure *get_displaced_step_closure_by_addr
(CORE_ADDR addr);
Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.173
diff -r1.173 varobj.c
299,301c299,301
< static struct varobj * varobj_add_child (struct varobj *var,
< 					 const char *name,
< 					 struct value *value);
---
> static struct varobj *varobj_add_child (struct varobj *var,
> 					const char *name,
> 					struct value *value);

Re: [RFA] Fix formatting in [RFA-v2] Fix ARI warning about function call in first column

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre>   Is this OK like below?

Yes.

Pierre>  Or should I still add the function declarations
Pierre> on which the change is applied (which I did not
Pierre> add in my previous ChangeLog entry).

I usually list them.

Tom

RE: [RFA] Fix formatting in [RFA-v2] Fix ARI warning about function call in first column

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : mardi 15 mars 2011 16:35
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFA] Fix formatting in [RFA-v2] Fix ARI warning about
> function call in first column
> 
> >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
> writes:
> 
> Pierre>   Is this OK like below?
> 
> Yes.

  Thansk, committed,
 
> Pierre>  Or should I still add the function declarations
> Pierre> on which the change is applied (which I did not
> Pierre> add in my previous ChangeLog entry).
> 
> I usually list them.

  With function names added...

Pierre

Re: [RFA-v2] Fix ARI warning about function call in first column

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Cc: <tromey@redhat.com>, <gdb-patches@sourceware.org>
> Date: Mon, 14 Mar 2011 18:01:54 +0100
> 
>   Here is what I finally checked in,
> it does avoid indented lone function names.

Thanks, this is fine with me.