From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14383 invoked by alias); 20 Oct 2008 19:03:20 -0000 Received: (qmail 14369 invoked by uid 22791); 20 Oct 2008 19:03:17 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Oct 2008 19:02:31 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw3.br.ibm.com (Postfix) with ESMTP id 10C47390292 for ; Mon, 20 Oct 2008 17:01:48 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9KJ2A5c2654354 for ; Mon, 20 Oct 2008 16:02:10 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9KJ2Lrt017072 for ; Mon, 20 Oct 2008 17:02:25 -0200 Received: from [9.8.2.108] ([9.8.2.108]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9KJ2JRb017038; Mon, 20 Oct 2008 17:02:19 -0200 Subject: Re: [RFC/RFA] add struct parse_context to all command functions From: Thiago Jung Bauermann To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20081020161614.GB6251@adacore.com> References: <20081009140424.GD5372@adacore.com> <20081020161614.GB6251@adacore.com> Content-Type: text/plain; charset=utf-8 Date: Mon, 20 Oct 2008 19:03:00 -0000 Message-Id: <1224529335.28191.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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: 2008-10/txt/msg00496.txt.bz2 El lun, 20-10-2008 a las 09:16 -0700, Joel Brobecker escribió: > Har har har, I should be able to be active again soon :-) Hooray. :-) > So we have 3 alternatives: > > 1. All command functions receive the parse_context structure. > Do the transition all at once. > > 2. All command functions should receive the parse_context structure. > Do the transition gradually by introducing a set of "old_add_..." > functions that allow to hook command functions that have the old > profile. > > 3. Only the command functions that needed it would be passed > the parse_context. Add a second set of add_... routines > to hook these command functions. > > I am 50/50 on (1) and (3). I like (2) a little less. Long term, > I think I prefer (1), but it's more painful in the short term. > I don't mind taking the initial hit, but other's opinion welcome. Is there any difference between (2) and (3) other than having the second set of ad__... routines have a prettier name in (3) than they'd have in (2)? You could do (3) first and then stop there, or use it as an intermediate step to get to (1). THe problem with (3) is that you make the code slightly more complex by adding an additional add_*_cmd that the GDB hacker will have to learn about. The advantage is that you can avoid writing functions with argument they'll never use. I mention this because the ProjectIdeas wiki page mentions that it's desirable to have GDB compile with -Wunused. IMHO I prefer to use (3) and have the option of using the -Wunused later (not that I'm stepping up to the task! :-) ). > Perhaps it's another bikeshed discussion, in which case let me know, > and I'll just decide on my own. Perhaps it is. It took me a while to decide which I thought was better, and then again I don't feel strong about either option. > It's just that it's such a large change > that I want to make sure I won't screw anyone up. Right, I'd also want input and some assurance before doing all this work... -- []'s Thiago Jung Bauermann IBM Linux Technology Center