From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4557 invoked by alias); 2 Sep 2005 14:26:43 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4209 invoked by uid 22791); 2 Sep 2005 14:25:58 -0000 Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.129) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 02 Sep 2005 14:25:58 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j82EPt8M212546 for ; Fri, 2 Sep 2005 10:25:55 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j82EPrRK353324 for ; Fri, 2 Sep 2005 08:25:54 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j82EPqIK020468 for ; Fri, 2 Sep 2005 08:25:52 -0600 Received: from dyn9047022123-009047022095.beaverton.ibm.com (dyn9047022123-009047022095.beaverton.ibm.com [9.47.22.95]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j82EPp42020433; Fri, 2 Sep 2005 08:25:51 -0600 From: Paul Gilliam Reply-To: pgilliam@us.ibm.com To: gdb-patches@sources.redhat.com Subject: Re: fix "too much information" bug w/ "info vector" on PowerPC Date: Fri, 02 Sep 2005 14:26:00 -0000 User-Agent: KMail/1.6.2 Cc: Daniel Jacobowitz , Jim Blandy References: <200508301459.57189.pgilliam@us.ibm.com> <20050902005525.GA30315@nevyn.them.org> In-Reply-To: <20050902005525.GA30315@nevyn.them.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200509020725.39063.pgilliam@us.ibm.com> X-SW-Source: 2005-09/txt/msg00009.txt.bz2 On Thursday 01 September 2005 17:55, Daniel Jacobowitz wrote: > On Thu, Sep 01, 2005 at 04:06:08PM -0700, Jim Blandy wrote: > > Paul Gilliam writes: > > > > > Talking about spaces, tabs, and formatting, I noticed that some of the function prototypes in ppc-tdep.h are over 80 columns and > > > real ugly. > > > > > > Here, for your consideration, are two patches to change that: one uses a short-lived macro (ppc-tdep.patch) and the other uses a > > > typedef (newest.patch). > > > > If I were to use a typedef, I'd put it in gdbarch.h and call it > > gdb_retval_convention_t; there's nothing special about ppc-tdep.h's > > needs. > > > > The following is also legal C, Emacs-friendly, and gdb_indent.sh-friendly: > > > > enum return_value_convention (ppc_sysv_abi_return_value > > (struct gdbarch *gdbarch, > > struct type *valtype, > > struct regcache *regcache, > > gdb_byte *readbuf, > > const gdb_byte *writebuf)); > > > > I used this once before, but Mark Kettenis declared it "weird" or > > something and asked me to take it out. :) Be that as it may, I think > > it's better than the macro or the local typedef. > > It is weird :-P > > What's so wrong with > > enum return_value_convention ppc_sysv_abi_return_value > (struct gdbarch *, struct type *, struct regcache *, > gdb_byte *, const gdb_byte *); > I noticed this style in other files: enum return_value_convention ppc_sysv_abi_return_value ( struct gdbarch *,struct type *, struct regcache *, gdb_byte *, const gdb_byte *); Which has the advantage of being able to search for the name with /^name/, for those who don't have 'ctabs' or 'etabs' :-) And for those compulsive commenters: enum return_value_convention ppc_sysv_abi_return_value ( struct gdbarch *, /* Silly comment about this argument */ struct type *, /* Silly comment about this argument */ struct regcache *, /* Silly comment about this argument */ gdb_byte *, /* Silly comment about this argument */ const gdb_byte *); /* Silly comment about this argument */ which realy works best on a definition, rather than a declartation. If someone wanted too, they could spend years trying to make the source consistant, not to mention how disruptive it would be to on-going development/support.