From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30492 invoked by alias); 13 Apr 2005 16:05:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30020 invoked from network); 13 Apr 2005 16:05:38 -0000 Received: from unknown (HELO dmz.algor.co.uk) (62.254.210.145) by sourceware.org with SMTP; 13 Apr 2005 16:05:38 -0000 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1DLkPL-00084z-00; Wed, 13 Apr 2005 17:08:03 +0100 Received: from perivale.mips.com ([192.168.192.200]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1DLkLO-0006H1-00; Wed, 13 Apr 2005 17:03:58 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1DLkLO-0003xv-00; Wed, 13 Apr 2005 17:03:58 +0100 Date: Wed, 13 Apr 2005 16:05:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Eli Zaretskii , gdb-patches@sources.redhat.com, "Maciej W. Rozycki" Subject: Re: Support for "break *ADDRESS thread THREADNO" In-Reply-To: <20050413120904.GA15220@nevyn.them.org> Message-ID: References: <20050412181334.GA2560@nevyn.them.org> <01c53f90$Blat.v2.4$17427900@zahav.net.il> <20050412185549.GA9715@nevyn.them.org> <20050413120904.GA15220@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.601, required 4, AWL, BAYES_00) X-SW-Source: 2005-04/txt/msg00112.txt.bz2 On Wed, 13 Apr 2005, Daniel Jacobowitz wrote: > > > I assume so. It is parsed as an expression, not just an address; for > > > instance "break *thread" would actually work if thread is a pointer to > > > a function. > > > > I think the actual problem is the expression parser cannot be told to > > stop successfully on an unparseable token as long as the expression > > collected so far is valid and let the caller deal with that. AFAICS the > > parser can only stop on a string terminator or optionally a comma, > > otherwise it issues an error. > > And - can yacc do that? No idea. With bison, according to documentation, the special "error" token might be a way of implementing that. But I haven't done any real lex/yacc coding for years, so I'd have to refresh my dusty memory. > Are you sure that there's no C expression that's valid with and without > a trailing identifier, by the way? I certainly find that believable, > but I haven't thought about it too hard. Well, with C it seems to be true -- I can't recall any expression where a trailing identifier would be valid if not preceded by either a type cast, which by itself is not a valid expression, or an operator that accepts a right-side operand, which cannot be left dangling either. But I'd have to have a look at the grammar spec to be sure I don't miss any obscure corner case. Maciej