From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18357 invoked by alias); 9 Mar 2004 21:27:39 -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 18340 invoked from network); 9 Mar 2004 21:27:39 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 9 Mar 2004 21:27:39 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B0olE-0002CT-Pk; Tue, 09 Mar 2004 16:27:36 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com, vinschen@redhat.com Subject: Re: [RFC/RFA] gdb.cp/classes.exp: Don't try to print local variable out of scope Message-ID: <20040309212736.GA8404@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com, vinschen@redhat.com References: <20040309161507.9FBF54B104@berman.michael-chastain.com> <404E2B2C.8030201@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404E2B2C.8030201@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00214.txt.bz2 Message-ID: <20040319000900.GvHXmhQumuH0grHlN6iBirKuXDtzSLDulMykjs8WYl0@z> On Tue, Mar 09, 2004 at 03:38:04PM -0500, Andrew Cagney wrote: > >1 void foo () > > 2 { > > 3 int i = 1; > > 4 { > > 5 int i = 2; > > 6 bar(i); > > 7 } > > 8 bar (i); > > 9 } > > > >cv> Is line 7 still in the scope of the inner definition of variable `i'? > >cv> Which `i' should be printed at that point? > > > >My intuition says that the inner "i" is in scope at line 7. > > Yes, the inner "i" should be in scope. That line, which hasn't yet been > executed, will destory the inner block. I think that is covered by the > GCC-O0 rule? If that's right, it sounds like we should be using the address-in-block hack to figure out what local variables are in scope for the top frame. But that runs the risk of, for instance, moving us back into a preceeding function. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer