From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17635 invoked by alias); 31 Dec 2011 07:27:53 -0000 Received: (qmail 17620 invoked by uid 22791); 31 Dec 2011 07:27:51 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB X-Spam-Check-By: sourceware.org Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 31 Dec 2011 07:27:35 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LX2002004GZBK00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Sat, 31 Dec 2011 09:27:33 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LX2002EW4PVBU00@a-mtaout23.012.net.il>; Sat, 31 Dec 2011 09:27:33 +0200 (IST) Date: Sat, 31 Dec 2011 08:58:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] Have block_innermost_frame start from selected frame In-reply-to: <20111230215222.86B713FEE8@kwai.gnat.com> To: Paul Hilfinger Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <8339c1td3u.fsf@gnu.org> References: <20111230215222.86B713FEE8@kwai.gnat.com> 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: 2011-12/txt/msg00915.txt.bz2 > From: Paul Hilfinger > Date: Fri, 30 Dec 2011 16:52:22 -0500 (EST) > > @@ -7304,12 +7304,13 @@ examine the variable @code{b} while your program is executing inside > the block where @code{b} is declared. > > @cindex variable name conflict > -There is an exception: you can refer to a variable or function whose > +You can refer to a variable or function whose > scope is a single source file even if the current execution point is not > in this file. But it is possible to have more than one such variable or > function with the same name (in different source files). If that > happens, referring to that name has unpredictable effects. If you wish, > -you can specify a static variable in a particular function or file, > +you can specify a static variable in a particular function or file by > +qualifying its name > using the colon-colon (@code{::}) notation: > > @cindex colon-colon, context for variables/functions This hunk seems to be limited to changes in style, rather than content. Can you tell why you thought these style changes are needed, in particular the first one? Also, I have reservations about using the term "qualifying" for this notation. Since we already use "scope resolution" for them in the C++ context, why not use "scope resolution" for C and other languages as well? > +unqualified name of the variable. However, you may also use this notation > +to refer to local variables in frames enclosing the selected frame: I'm not sure "enclosing frame" is clear enough. I think we tend to use "outer frame" elsewhere in the manual. Alternatively, you could use "enclosing scope". > +@smallexample > +(@value{GDBP}) p a > +(@value{GDBP}) p bar::a > +(@value{GDBP}) up 2 > +(@value{GDBP}) p a > +(@value{GDBP}) p bar::a > + > +@end smallexample Please remove the empty line before "@end smallexample". Anyway, this begs the question: is the scope resolution available only for print commands, or also in other commands, like `watch'? If the latter can also use this, then I think we should mention that, here and where watchpoints are described. If the `watch' command cannot use this, then it sounds like we are inconsistent here. Thanks.