From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17700 invoked by alias); 11 Jan 2008 19:44:25 -0000 Received: (qmail 17686 invoked by uid 22791); 11 Jan 2008 19:44:25 -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; Fri, 11 Jan 2008 19:44:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 46D3F2A960C; Fri, 11 Jan 2008 14:44:02 -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 TlxDCoFcXAAa; Fri, 11 Jan 2008 14:44:02 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A95D72A960A; Fri, 11 Jan 2008 14:44:01 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id BA84AE7ACB; Fri, 11 Jan 2008 11:43:53 -0800 (PST) Date: Fri, 11 Jan 2008 19:44:00 -0000 From: Joel Brobecker To: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: [RFC/RFA] Wrong documentation for "&&var"? Message-ID: <20080111194353.GA9143@adacore.com> References: <20080108065524.GA24614@adacore.com> <20080108204130.GA8365@caradoc.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20080108204130.GA8365@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-01/txt/msg00283.txt.bz2 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 706 > > The original text was there since the first version in CVS (in 1999), > > so I'm inclined to think it's a bug in the parser. > > >From what I know about parsing C, I suggest we go with the > documentation change. && is a single token, and && NAME is not > currently valid. It would introduce some ambiguities into the > grammer, I suspect. So Eli, do you agree with the documentation change? We can always redocument this later if we manage to make it work... Let me resend the patch: 2008-01-08 Paul Hilfinger * gdb.texinfo (C Operators): Remove incorrect parenthetical comment about &&var, which is rejected by the expression parser. Thanks, -- Joel --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="formatted-doc.diff" Content-length: 546 Index: gdb.texinfo =================================================================== --- gdb.texinfo (revision 89) +++ gdb.texinfo (revision 90) @@ -9250,7 +9250,7 @@ Address operator. Defined on variables. For debugging C@t{++}, @value{GDBN} implements a use of @samp{&} beyond what is allowed in the C@t{++} language itself: you can use @samp{&(&@var{ref})} -(or, if you prefer, simply @samp{&&@var{ref}}) to examine the address +to examine the address where a C@t{++} reference variable (declared with @samp{&@var{ref}}) is stored. --9jxsPFA5p3P2qPhR--