From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15376 invoked by alias); 17 Feb 2006 14:11:06 -0000 Received: (qmail 15367 invoked by uid 22791); 17 Feb 2006 14:11:06 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 14:11:05 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HXF05774; Fri, 17 Feb 2006 16:10:52 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-80-230-10-40.inter.net.il [80.230.10.40]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CSN31707 (AUTH halo1); Fri, 17 Feb 2006 16:10:45 +0200 (IST) Date: Fri, 17 Feb 2006 14:11:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: <200602171658.23427.ghost@cs.msu.su> (message from Vladimir Prus on Fri, 17 Feb 2006 16:58:22 +0300) Subject: Re: MI: type prefixes for values Reply-to: Eli Zaretskii References: <200602171450.16858.ghost@cs.msu.su> <200602171658.23427.ghost@cs.msu.su> X-IsSubscribed: yes 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/msg00176.txt.bz2 > From: Vladimir Prus > Date: Fri, 17 Feb 2006 16:58:22 +0300 > Cc: gdb@sources.redhat.com > > > > It's only avaiable in tooltip text for a variable. So far, no complaints. > > > > I don't see how is this contrary to what GDB assumes. GDB passes the > > information to the front end; how the front end displays it, is > > entirely up to the front end. > > Because for display in variable tree, frontend prefers not to show any type, > and for display in varible tooltips, it prefers to show the type after the > value, not before. That's quite specific to that front end, right? We cannot possibly assume they all will behave like that. > > > In the output of print, the type of variable is sometimes wrapped in > > > {}, sometimes in (), and there are no formal rules a frontend author > > > can use to extract type from this information. > > > > The formal rules can be stated, if that's what is missing. The code > > that produces the parentheses is deterministic, so the rules for when > > they are used can be defined. > > Sure, they can be stated. But: > - I don't think anobody is working on that Volunteers are welcome. > - The parsing of that value will have to be done by ad-hoc code, which is > contrary to MI-goal of being easily parsable. Why ad-hoc? if you have {}, parse it, if not, don't. Why is this simple rule hard for a parser? > > Then perhaps we should add the type info to all arguments, instead of > > removing it from where it exists now. > > It might be good idea, but why don't add it as a separate field? I.e. instead > of > > ^done,value="(int *) 0x0" > > you'll get > > ^done,value="0x0",type="int *" Fine with me.