From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4304 invoked by alias); 19 Mar 2011 17:32:25 -0000 Received: (qmail 4296 invoked by uid 22791); 19 Mar 2011 17:32:25 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_BJ,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 19 Mar 2011 17:32:20 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id p2JHUpxt030264; Sat, 19 Mar 2011 18:30:51 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id p2JHUnQk025106; Sat, 19 Mar 2011 18:30:49 +0100 (CET) Date: Sat, 19 Mar 2011 21:15:00 -0000 Message-Id: <201103191730.p2JHUnQk025106@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: pierre.muller@ics-cnrs.unistra.fr CC: eliz@gnu.org, pedro@codesourcery.com, gdb-patches@sourceware.org In-reply-to: <001b01cbe253$048d6790$0da836b0$@muller@ics-cnrs.unistra.fr> (pierre.muller@ics-cnrs.unistra.fr) Subject: Re: New ARI warning Sat Mar 12 01:53:29 UTC 2011 References: <20110312015329.GA20179@sourceware.org> <201103141213.43979.pedro@codesourcery.com> <201103141251.31400.pedro@codesourcery.com> <001b01cbe253$048d6790$0da836b0$@muller@ics-cnrs.unistra.fr> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00938.txt.bz2 > From: "Pierre Muller" > 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 > <<>>> > extern struct hppa_objfile_private * > hppa_init_objfile_priv_data (struct objfile *objfile); > <<>>> > into: > > <<>>> > extern struct hppa_objfile_private * > hppa_init_objfile_priv_data (struct objfile *objfile); > <<>>> > > Your suggestion would lead to: > <<>>> > extern struct hppa_objfile_private * hppa_init_objfile_priv_data (struct > objfile *objfile); > <<>>> > > 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: > > <<>>> > 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); > <<>>> > > 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.