From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2376 invoked by alias); 22 Oct 2008 01:40:41 -0000 Received: (qmail 2367 invoked by uid 22791); 22 Oct 2008 01:40:41 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Oct 2008 01:40:05 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9F9A92A96A2; Tue, 21 Oct 2008 21:40:03 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JsO6VS0y-g10; Tue, 21 Oct 2008 21:40:03 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 56B0D2A968B; Tue, 21 Oct 2008 21:40:03 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E9809E7AD0; Tue, 21 Oct 2008 18:40:00 -0700 (PDT) Date: Wed, 22 Oct 2008 01:40:00 -0000 From: Joel Brobecker To: Ulrich Weigand , Thiago Jung Bauermann , gdb-patches@sourceware.org Subject: Re: [RFC/RFA] add struct parse_context to all command functions Message-ID: <20081022014000.GA3638@adacore.com> References: <20081021004630.GA6571@caradoc.them.org> <200810211805.m9LI5Lt0014410@d12av02.megacenter.de.ibm.com> <20081021181739.GA10391@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081021181739.GA10391@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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/msg00531.txt.bz2 > Listening to Tom talk about this I've started to wonder if it's > necessary... do we have a unified vision on where the global state > accesses are OK? I think it will depend on each global. For the current_language and the input_radix, my goal is to have it used only from the command line loop that calls the command functions. > GDB is single threaded. I anticipate it will remain so. So, having > the functions which implement user interface commands read global > state doesn't seem like a big problem - unlike the expression parser. I initially thought that it would be OK to have the command functions that need it access current_language. But I quickly realized that this was actually pretty confusing. In order to audit the use of a current_language, you'd have to check what the function using it is used for - in particular, make sure that it's used as a command function. When you have zillions of them spread everywhere in the code, it's nearly impossible to avoid re-introducing incorrect uses of the global. With the approach that I suggest where I add the parameter, I should be able to never increase the number of references to current_language (and input_radix). And eventually, I should be able to eliminate them all, save a couple of places where we know it's OK. I will wait another couple of days to see how people react, but it seems at this point that everyone was OK with approach (1), where I do the transition all in one go. And since Tom was the lead "questioner" of this change, I'd like to mention that my understanding is that Tom understands the benefits of adding the extra parameter, given the above explaination. Tom, please yell if I misunderstood you! If all is well, I hope to be able to start looking into this sometime late this week or maybe early next week. -- Joel