From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3992 invoked by alias); 8 Jan 2008 06:55:52 -0000 Received: (qmail 3984 invoked by uid 22791); 8 Jan 2008 06:55:51 -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; Tue, 08 Jan 2008 06:55:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B75F92A9682 for ; Tue, 8 Jan 2008 01:55:32 -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 00O7+JbNDpWR for ; Tue, 8 Jan 2008 01:55:32 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2F2B32A966F for ; Tue, 8 Jan 2008 01:55:32 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id CE896E7ACB; Mon, 7 Jan 2008 22:55:24 -0800 (PST) Date: Tue, 08 Jan 2008 06:55:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFC/RFA] Wrong documentation for "&&var"? Message-ID: <20080108065524.GA24614@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline 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/msg00125.txt.bz2 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 584 Hello, Paul noticed the following. 2008-01-08 Paul Hilfinger * gdb.texinfo (C Operators): Remove incorrect parenthetical comment about &&var, which is rejected by the expression parser. Not knowing what was really meant at the implementation level, I'm not sure whether this is a parser implementation bug, or an error in the documentation. Paul thought that this was an error in the documentation so, assuming he is correct, I'm submitting this change on his behalf. So, is this a parser bug or a documentation error? Thanks, -- Joel --YZ5djTAD1cGYuMQK 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. --YZ5djTAD1cGYuMQK--