From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15062 invoked by alias); 22 Dec 2006 07:23:56 -0000 Received: (qmail 15025 invoked by uid 22791); 22 Dec 2006 07:23:53 -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, 22 Dec 2006 07:23:44 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Gxekk-0003rX-DY for gdb-patches@sources.redhat.com; Fri, 22 Dec 2006 10:23:39 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Gxekf-0003rI-FZ; Fri, 22 Dec 2006 10:23:33 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: RFC: MI - Detecting change of string contents with variable objects Date: Fri, 22 Dec 2006 07:23:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <17797.65268.689590.797944@kahikatea.snap.net.nz> <200612220915.34288.ghost@cs.msu.su> <17803.34115.206621.977511@kahikatea.snap.net.nz> In-Reply-To: <17803.34115.206621.977511@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: <200612221023.31460.ghost@cs.msu.su> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00305.txt.bz2 On Friday 22 December 2006 10:12, Nick Roberts wrote: > > > Because -var-evaluate-expression uses varobj_get_value so they will always > > > return the same value? > > > > Then, there are two solutions: > > We seem to be agree that the patch does the right thing and are just talking > about implementation details. Yes. > > > 1. Make c_value_of_variable and friends accept struct value as opposed to > > taking struct varobj. > > c_value_of_variable, as it's name implies, requires a struct varobj as it's > argument. You can renamed it to anything you want, say "c_format_value", or whatever. > > 2. Extra the part of c_value_of_variable that you've based your function on > > into a separate function. Make both c_value_of_variable and install_new_value > > call the new function. > > value_get_print_value is quite a small function. After you've wrapped > some statements in if clauses and worked out how to call them with a > common argument, I can't see that you would gain much. > > > I'm not sure which approach you find better, but I don't think copy-pasting > > is a solution to anything. > > Clearly it is *a* solution, it's just a question of whether it's the *best* > solution in this case. Anyway, it's not a straight copy-paste (the asserts are > removed, for example). Probably it's perfectionism, but if we want -var-update to return a varobj if the result of -var-evaluate-expression would be different, then we must execute the same code as for -var-evaluate-expression when deciding if the value has changed. If you run some other code, however similar *now*, it's very likely that soon things will break. > I think if you look through the code you'll find > numerous examples where one section of code is a slight variation of another. Yes. I'd like to remove all such cases. - Volodya