From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20027 invoked by alias); 31 Dec 2011 20:11:29 -0000 Received: (qmail 20017 invoked by uid 22791); 31 Dec 2011 20:11:25 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 31 Dec 2011 20:11:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 58E4E2BADAF; Sat, 31 Dec 2011 15:11:11 -0500 (EST) 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 fAa5fe2BbEJH; Sat, 31 Dec 2011 15:11:11 -0500 (EST) Received: from kwai.gnat.com (kwai.gnat.com [205.232.38.4]) by rock.gnat.com (Postfix) with ESMTP id 3D65A2BADA9; Sat, 31 Dec 2011 15:11:11 -0500 (EST) Received: by kwai.gnat.com (Postfix, from userid 1345) id 3640592BF6; Sat, 31 Dec 2011 15:11:11 -0500 (EST) From: Paul Hilfinger To: Eli Zaretskii CC: gdb-patches@sourceware.org In-reply-to: <8339c1td3u.fsf@gnu.org> (message from Eli Zaretskii on Sat, 31 Dec 2011 09:27:33 +0200) Subject: Re: [RFA] Have block_innermost_frame start from selected frame Reply-to: Hilfinger@adacore.com References: <20111230215222.86B713FEE8@kwai.gnat.com> <8339c1td3u.fsf@gnu.org> Message-Id: <20111231201111.3640592BF6@kwai.gnat.com> Date: Sat, 31 Dec 2011 21:40:00 -0000 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/msg00920.txt.bz2 > > @@ -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? > I'm not wed to these changes. The first one is accidental: I had wanted to modify the section so that first it talked about unqualified uses and then turned to qualified uses, not as an "exception" but rather as a separate case. Apparently, I neglected to modify the preceding portion to specifically say it concerned unqualified variables. The second change was to introduce the term "qualified". However, it also corrects a slight problem---that comma after "file," is out of place, I think. However, if you don't like "qualifying", I am happy to remove both changes. > > +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". > Yeah, but I really need to say something like "frames that are at or outside the selected frame". Would that be understandable terminology, do you think? I don't like "enclosing scope". We are dealing with statically scoped languages, where "enclosing scope" usually means "lexically enclosing scope", and that is not what we are talking about here. > > +@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". Right. > 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. > Well, since I don't see any circular arguments here, I wouldn't say that any questions are being begged [sorry: obligatory pedantry there], but you are certainly right that it does raise the question of general applicability. The section is about "Program variables" but all examples use 'print'. Furthermore, you are correct that watch behaves incorrectly at the moment: it picks up the correct variable value when 'watch' is issued, but then reverts to the old behavior when deciding which variable to watch, giving nonsensical results. I will have to revise the patch. Thanks for catching this. -- Paul N. Hilfinger (Hilfinger@adacore.com)