From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12851 invoked by alias); 4 Oct 2002 00:22:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12807 invoked from network); 4 Oct 2002 00:22:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 4 Oct 2002 00:22:08 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g94033008798 for ; Thu, 3 Oct 2002 20:03:03 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g940M7f26878; Thu, 3 Oct 2002 20:22:07 -0400 Received: from valrhona.uglyboxes.com (IDENT:O54DOBpk4ZYC64Da6p9J0kWPst8CHIfe@vpn50-40.rdu.redhat.com [172.16.50.40]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g940M6909388; Thu, 3 Oct 2002 20:22:06 -0400 Date: Thu, 03 Oct 2002 17:22:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: "J. Johnston" cc: gdb-patches@sources.redhat.com, Subject: Re: Patch for gdb/mi problem 702 In-Reply-To: <3D9CCD77.A189328C@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00118.txt.bz2 On Thu, 3 Oct 2002, J. Johnston wrote: > The following fixes a problem with -var-assign whereby an assignment > of a new value is not seen by a subsequent -var-update. The > underlying varobj_update call looks to see if there is a difference > between the current value and a refreshed value. Since varobj_set_value > actually changes both the internal value and the actual value, varobj_update > does not add the variable to the changelist. The real question is: is it really necessary for an assignment to show up in the udpate list. IMO, it doesn't matter, because the caller will know if the assignment succeeded or failed. If it failed, it'll have an error message from MI. Otherwise, it knows that it worked and all it needs to do is fetch the value of this variable (to get the right display format) and update the displayed value on the screen. There's no reason to do an update, which is not a cheap operation. I really don't know what to make of this. I don't think this is really necessary. It seems like a substitute for error checking. Perhaps Alain can comment on why this is necessary with Eclipse? Keith