From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13780 invoked by alias); 29 Jul 2008 22:53:36 -0000 Received: (qmail 13770 invoked by uid 22791); 29 Jul 2008 22:53:35 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jul 2008 22:53:17 +0000 Received: by fg-out-1718.google.com with SMTP id e12so18224fga.0 for ; Tue, 29 Jul 2008 15:53:14 -0700 (PDT) Received: by 10.86.96.18 with SMTP id t18mr4143850fgb.78.1217371994452; Tue, 29 Jul 2008 15:53:14 -0700 (PDT) Received: by 10.86.98.13 with HTTP; Tue, 29 Jul 2008 15:53:14 -0700 (PDT) Message-ID: Date: Tue, 29 Jul 2008 22:53:00 -0000 From: "Rob Quill" To: "Tom Tromey" Subject: Re: New scope checking patch Cc: "Eli Zaretskii" , "Jim Blandy" , gdb-patches@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8f2776cb0801301557t2e265b62u56d6df7cbcec1c84@mail.gmail.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: 2008-07/txt/msg00556.txt.bz2 2008/7/29 Tom Tromey : > Rob> If this patch it implemented as an internal function, what is to > Rob> stop someone passing an expression to $in_scope(), in which case, > Rob> does the patch need to be able to determine if a whole expression > Rob> is in scope? > > In the internal-function form, in_scope would take a string-valued > argument. So, the expression would be evaluated first -- just like > any other function argument -- and then passed to the in_scope > primitive. > > I guess this would prevent easy checking of whether an entire > expression is in scope. (BTW does that mean just checking all the > names in the expression?) Yep. Exactly. I just checked and found I had discussed the problem I had in the first post in this thread. "There is a caveat with the patch which is as follows. If a variable is not in scope then the expression parser in c-exp.y inserts a value 0 into the expression tree. When the scope checking function sees a 0 expression in the tree it will return 0, to indicate not in scope. However, in the general case it should be true that all literals are in scope. However, due to the above caveat $in_scope(0) will return 0, any any other literal will return 1. This also affects compound expressions that involve the literal 0. For example, $in_scope(0+3) will return 0, as an expression with a binary operator is considering in scope iff both of its operands are in scope." Obviously this disappears though with the current patch as it can't deal with compound expressions. Rob