From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8136 invoked by alias); 17 Dec 2002 21:59:21 -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 8095 invoked from network); 17 Dec 2002 21:59:19 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 17 Dec 2002 21:59:19 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gBHLx7111513; Tue, 17 Dec 2002 13:59:07 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Paul Hilfinger Cc: gdb Subject: Re: c-exp.y References: <200212172143.NAA14438@tully.CS.Berkeley.EDU> From: David Carlton Date: Tue, 17 Dec 2002 13:59:00 -0000 In-Reply-To: <200212172143.NAA14438@tully.CS.Berkeley.EDU> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00264.txt.bz2 On Tue, 17 Dec 2002 13:43:22 -0800, Paul Hilfinger said: >> Unfortunately, some sort of distinction between types and non-types >> seems to be hard-wired into the parser at a deep level: it seems to >> be the parser's job to actually evaluate expressions corresponding >> to types, whereas other expressions get evaluated by somebody else. > Yes. This is a well-known issue with C++ parsing. 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. Basically, what the parser is trying to parse isn't a C++ expression (which, as you point out, is ridiculously difficult if you really want to do it correctly) but is instead either an expression or a type, so that the same parser can be used unmodified for either GDB's 'print' command or its 'ptype' command. I could be wrong, though. David Carlton carlton@math.stanford.edu