From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1337 invoked by alias); 17 Feb 2006 13:58:36 -0000 Received: (qmail 1329 invoked by uid 22791); 17 Feb 2006 13:58:35 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 13:58:34 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FA67z-0001lq-6N for gdb@sources.redhat.com; Fri, 17 Feb 2006 16:58:31 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FA67s-0001lX-QA; Fri, 17 Feb 2006 16:58:24 +0300 From: Vladimir Prus To: Eli Zaretskii Subject: Re: MI: type prefixes for values Date: Fri, 17 Feb 2006 13:58:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <200602171450.16858.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602171658.23427.ghost@cs.msu.su> 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/msg00173.txt.bz2 On Friday 17 February 2006 16:49, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Fri, 17 Feb 2006 14:50:16 +0300 > > > > On Friday 17 February 2006 14:26, Eli Zaretskii wrote: > > > > From: Vladimir Prus > > > > Date: Fri, 17 Feb 2006 13:29:33 +0300 > > > > Cc: gdb@sources.redhat.com > > > > > > > > > Are you saying that you don't want to show your users the fact that > > > > > the pointed object is a function? > > > > > > > > At the very least, not in the way that gdb assumes. > > > > > > In what way, then? > > > > 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. > The important thing is, you do use this information. > > > 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 - The parsing of that value will have to be done by ad-hoc code, which is contrary to MI-goal of being easily parsable. > > > and why should we force the front end to send > > > yet another command to get this information? > > > > Because it has to do this anyway -- the type is embedded in value only > > for some special types, and frontend needs type information anyway. > > 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 *" In that case, we don't need to document how type is added to value, and frontend author don't need to extract the type in ad-hoc way, he's just use regular way to access MI field value. - Volodya