From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7419 invoked by alias); 9 Dec 2006 21:38:04 -0000 Received: (qmail 7408 invoked by uid 22791); 9 Dec 2006 21:38:03 -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; Sat, 09 Dec 2006 21:37:54 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Gt9tF-0001ZX-Px for gdb-patches@sources.redhat.com; Sun, 10 Dec 2006 00:37:50 +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 1Gt9t6-0001ZK-EJ; Sun, 10 Dec 2006 00:37:40 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: MI: fix base members in references Date: Sat, 09 Dec 2006 21:38:00 -0000 User-Agent: KMail/1.9.1 References: <17787.10504.215397.177658@kahikatea.snap.net.nz> In-Reply-To: <17787.10504.215397.177658@kahikatea.snap.net.nz> Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612100037.24768.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/msg00143.txt.bz2 On Sunday 10 December 2006 00:22, you wrote: > > > > The patch below seems to fix it for me. Its a diff on 1.63 _with_ your > > > yet to be committed changes. > > > I would have preferred if instead of adding if, the code was modified to > > look at > > > value_type (var->value) > > > as opposed to > > > var->type > > I'm not sure that I follow your point. The patch just gets the target type, > after dereferencing, in the case of a pointer. > > > The latter is the type of the varobj expression as it is in source program. > > The former is the value we're actually showing. It makes sense to use > > value_type (var->value) for all presentation purposes. > > The former appears to be a type also (not a value). Slight typo: the former is the type of the value we're actually showing. So, you don't need to take original type and try to arrived to the type that should be shown to the user, you just use value_type (var->value), and don't need any further processing. One less thing that can be broken in future. - Volodya