From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25618 invoked by alias); 19 Dec 2002 03:36:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25609 invoked from network); 19 Dec 2002 03:36:34 -0000 Received: from unknown (HELO tully.CS.Berkeley.EDU) (128.32.153.227) by 209.249.29.67 with SMTP; 19 Dec 2002 03:36:34 -0000 Received: from tully.CS.Berkeley.EDU (hilfingr@localhost) by tully.CS.Berkeley.EDU (8.9.1a/8.9.1) with ESMTP id TAA20859; Wed, 18 Dec 2002 19:36:22 -0800 (PST) Message-Id: <200212190336.TAA20859@tully.CS.Berkeley.EDU> To: David Carlton cc: gdb Subject: Re: c-exp.y In-Reply-To: Message from David Carlton of "Tue, 17 Dec 2002 13:59:07 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20854.1040268981.1@tully.CS.Berkeley.EDU> Date: Wed, 18 Dec 2002 19:36:00 -0000 From: Paul Hilfinger X-SW-Source: 2002-12/txt/msg00285.txt.bz2 > I have heard that C++ parsing is a royal pain, but I'm not sure that's > the issue here: I suspect that GDB's problems are at a more basic > level. I suspect that the division of labor between what the > parse_expression does and what eval_expression does is a bit funny, > and I'm pretty sure that the rule > > start : exp1 > | type_exp > ; > > in the parser leads to some conceptual incoherence. It does, but it is not alone, which I guess was my point. Look further down in the grammar, and you find exp : '(' type ')' exp %prec UNARY ... ; exp : '(' exp1 ')' { } which is essentially the same thing all over again. The point is that there are instances in the C/C++ grammar that require knowing whether a given identifier or qualified name is or is not a type, which is why this sort of stuff tends to migrate into lexical analysis. Paul Hilfinger