From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4000 invoked by alias); 10 Nov 2006 21:06:27 -0000 Received: (qmail 3981 invoked by uid 22791); 10 Nov 2006 21:06:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Nov 2006 21:06:18 +0000 Received: (qmail 19757 invoked from network); 10 Nov 2006 21:06:17 -0000 Received: from unknown (HELO ?172.16.64.38?) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Nov 2006 21:06:17 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: -var-show-attributes response syntax Date: Fri, 10 Nov 2006 21:06:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb@sources.redhat.com References: <200611101655.32843.vladimir@codesourcery.com> <17748.58492.703620.633216@kahikatea.snap.net.nz> In-Reply-To: <17748.58492.703620.633216@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611110006.06389.vladimir@codesourcery.com> 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-11/txt/msg00063.txt.bz2 On Friday 10 November 2006 23:43, Nick Roberts wrote: > > > I see no advantage in restricting the output but I've not used this > > > command. How do you want to use it? > > > > I want to add a new attribute there, actually, and I'd prefer to use > > more regular name=value syntax. > > That's still a bit vague. > > You say: > > How about changing the above to "editable=0/1"? > > Are you suggesting > > ^done,attr="editable=0", ^done,attr="editable=1" > > or > > ^done,editable="0", ^done,editable="1" The latter. > Either case still requires the front end to do some string > manipulation/comparison. I don't follow -- every syntax requires some string manipulation. In fact, "name=value" syntax is used in many other places so frontend already knows how to parse it. > Can you state precisely how you would change the > format and precisely what the benefit would be? The benefit is consistency with other MI response. > > > > This sounds like > > > > breaking > > > > backward compatibility, but probably is not, because "editable" is > > > > broken itself: > > > > > > > > -var-create C * 1+1 > > > > ^done,name="C",numchild="0",type="long" > > > > (gdb) > > > > -var-show-attributes C > > > > ^done,attr="editable" > > > > (gdb) > > > > > > Why do you think this is broken? > > > > Because you can't assign the value to "1+1" -- it's not lvalue. And > > trying to do so will result in error from gdb. > > I see, I missed that. In fact it my example was also wrong too, constants > in C appear to be editable. Noneditables appear to be arrays, structures, > unions etc. However I think this a separate issue to changing the syntax. I meant to say that this command does not seem to have useful semantic, so backward compatibility is not that important with it. - Volodya