From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9493 invoked by alias); 17 Feb 2006 19:36:02 -0000 Received: (qmail 9462 invoked by uid 22791); 17 Feb 2006 19:36:01 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 19:35:59 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060217193600.FQYC4894.eastrmmtao01.cox.net@localhost.localdomain>; Fri, 17 Feb 2006 14:36:00 -0500 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FABOY-00051p-Ee; Fri, 17 Feb 2006 14:35:58 -0500 Date: Fri, 17 Feb 2006 19:44:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI: type prefixes for values Message-ID: <20060217193558.GD14873@brasko.net> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com References: <200602171658.23427.ghost@cs.msu.su> <200602171724.03824.ghost@cs.msu.su> <20060217190418.GA27304@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00196.txt.bz2 On Fri, Feb 17, 2006 at 09:25:42PM +0200, Eli Zaretskii wrote: > > Date: Fri, 17 Feb 2006 14:04:18 -0500 > > From: Daniel Jacobowitz > > Cc: Vladimir Prus , gdb@sources.redhat.com > > > > To correct the record, he's not parsing MI here. He's parsing the > > value encapsulated within MI, the bit in quotes here: > > value="4000" > > or: > > value="{int (int)} 0xffffffff " > > I understood that part. > > > There's no grammar describing what goes in the value string. > > How do you mean ``there's no grammar''? Do you mean it cannot be > written? Or do you mean it was not written yet? If the latter, then > if I needed to write a code to parse this, I'd write down a formal > definition of what I'll expect, before writing code to parse that. Eli, I'm suggesting that there is not, and can never be a reliable formal description for parsing the data in the field 'value'. GDB is free to change that string to whatever it wants in the future. That string is not supposed to be parsed. So don't do it. If GDB wants that data to be parsable, it would need to describe a language that could parse it, and FE's could implement it. But what would be the point? Vladimir, stop trying to parse fields that are unparsable by nature. If you want to parse the data, your on your own. If you submit a patch that makes GDB output data in more atomic pieces, I think everyone would be OK with that. Bob Rossi