From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: <tromey@redhat.com>, <gdb-patches@sourceware.org>
Subject: RE: [RFA-v2] Fix ARI warning about function call in first column
Date: Mon, 14 Mar 2011 17:26:00 -0000 [thread overview]
Message-ID: <002001cbe269$85ed0e60$91c72b20$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <83oc5dr6pj.fsf@gnu.org>
> -----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
next prev parent reply other threads:[~2011-03-14 17:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-12 2:17 New ARI warning Sat Mar 12 01:53:29 UTC 2011 GDB Administrator
2011-03-13 9:32 ` Pierre Muller
2011-03-13 10:24 ` [RFA] Fix ARI warning about function call in first column (was : New ARI warning Sat Mar 12 01:53:29 UTC 2011) Pierre Muller
2011-03-13 13:42 ` [RFA] Fix ARI warnings about function with no parameters ( " Pierre Muller
2011-03-14 16:03 ` Pierre Muller
2011-03-13 19:39 ` New ARI warning Sat Mar 12 01:53:29 UTC 2011 Eli Zaretskii
2011-03-14 11:26 ` Pierre Muller
2011-03-14 12:13 ` Eli Zaretskii
2011-03-14 12:34 ` Pedro Alves
2011-03-14 12:34 ` Eli Zaretskii
2011-03-14 12:49 ` Pierre Muller
2011-03-14 13:06 ` Eli Zaretskii
2011-03-14 12:51 ` Eli Zaretskii
2011-03-14 12:52 ` Pierre Muller
2011-03-14 13:16 ` Eli Zaretskii
2011-03-14 12:59 ` Pedro Alves
2011-03-14 13:27 ` Eli Zaretskii
2011-03-14 13:46 ` Pedro Alves
2011-03-14 15:46 ` Pierre Muller
2011-03-19 21:15 ` Mark Kettenis
[not found] ` <18667.385276831$1300008680@news.gmane.org>
2011-03-14 15:54 ` [RFA] Fix ARI warning about function call in first column Tom Tromey
2011-03-14 16:46 ` [RFA-v2] " Pierre Muller
2011-03-14 17:02 ` Tom Tromey
[not found] ` <001401cbe261$5490ec40$fdb2c4c0$%muller@ics-cnrs.unistra.fr>
2011-03-14 17:17 ` Eli Zaretskii
2011-03-14 17:26 ` Pierre Muller [this message]
[not found] ` <10281.0550401502$1300122152@news.gmane.org>
2011-03-14 17:39 ` Tom Tromey
2011-03-15 12:19 ` [RFA] Fix formatting in " Pierre Muller
[not found] ` <45563.9187516228$1300186224@news.gmane.org>
2011-03-15 15:42 ` Tom Tromey
2011-03-15 16:01 ` Pierre Muller
[not found] ` <002001cbe269$85ed0e60$91c72b20$%muller@ics-cnrs.unistra.fr>
2011-03-14 21:26 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='002001cbe269$85ed0e60$91c72b20$@muller@ics-cnrs.unistra.fr' \
--to=pierre.muller@ics-cnrs.unistra.fr \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox