From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2546 invoked by alias); 5 May 2006 23:30:47 -0000 Received: (qmail 2538 invoked by uid 22791); 5 May 2006 23:30:47 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 May 2006 23:30:44 +0000 Received: from farnswood.snap.net.nz (p202-124-114-176.snap.net.nz [202.124.114.176]) by viper.snap.net.nz (Postfix) with ESMTP id 2DAF57547B1; Sat, 6 May 2006 11:30:41 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id B7A18627ED; Sat, 6 May 2006 00:29:58 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17499.57333.952984.589237@farnswood.snap.net.nz> Date: Fri, 05 May 2006 23:30:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH]: MI -var-set-format In-Reply-To: <20060505181111.GI31029@nevyn.them.org> References: <17494.64020.26176.277202@farnswood.snap.net.nz> <20060505181111.GI31029@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.50.43 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00128.txt.bz2 > > I would like to add the value in the (new) current format, which I find > > much more useful: > > > > -var-set-format var1 hexadecimal > > ^done,format="hexadecimal",value="0x12" > > > > OK to apply if I update the testsuite accordingly? > > This seems reasonable; I doubt anyone will object. > > I was wondering how to handle potential error conditions. I see at > least two: > > - The return of varobj_get_value can be NULL. You should check for > that. That often happens already. I don't see a real problem: the null string gets returned and nothing gets printed for the value. > - common_val_print might fail to transform the struct value * into > a string for some reason. I believe it may call error() if that > happens. I don't know what the reason would be. However, the value is printed via varobj_get_value for many other MI commands e.g -var-evaluate-expression, -var-list-children --all-values, -var-update --all-values -- and I've not seen it call an error yet > Should -var-set-format fail in those cases, or should it omit the > value, or should it supply a default value string (e.g. )? It > will have changed the varobj's settings, so I don't think ^error > is appropriate. Eventually I guess it might be a good idea to distinguish between a NULL pointer and a string that has the value NULL, but I presume any such changes would be to varobj_get_value and so are orthogonal to my patch. -- Nick http://www.inet.net.nz/~nickrob