From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <archer-return-1687-listarch-archer=sourceware.org@sourceware.org>
Received: (qmail 32106 invoked by alias); 25 Sep 2009 19:19:09 -0000
Mailing-List: contact archer-help@sourceware.org; run by ezmlm
Sender: <archer@sourceware.org>
Precedence: bulk
List-Post: <mailto:archer@sourceware.org>
List-Help: <mailto:archer-help@sourceware.org>
List-Subscribe: <mailto:archer-subscribe@sourceware.org>
List-Id: <archer.sourceware.org>
Received: (qmail 32092 invoked by uid 22791); 25 Sep 2009 19:19:08 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0
	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4ABD179F.6050006@googlemail.com>
Date: Fri, 25 Sep 2009 19:19:00 -0000
From: Richard Ward <richard.j.ward1@googlemail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Tom Tromey <tromey@redhat.com>
CC: archer@sourceware.org
Subject: Re: Patch to add rtti_type member to gdb.Value
References: <4ABA6ADD.4000003@googlemail.com> <m3fxaayhh8.fsf@fleche.redhat.com>
In-Reply-To: <m3fxaayhh8.fsf@fleche.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2009-q3/txt/msg00253.txt.bz2

Tom Tromey wrote:
>>>>>> "Richard" == Richard Ward <richard.j.ward1@googlemail.com> writes:
> 
> Richard> This patch adds value gdb.Value.rtti_type to go along side
> Richard> gdb.Value.type. the type represents the type of the value determined
> Richard> by rtti. Luckily it turns out that the info is already available in
> Richard> gdb's value struct, where it has already been properly determined, so
> Richard> there is no need to call any real gdb code. This just exposes
> Richard> it.
> 
> Is that always the case?  I ask because other code, like the code
> implementing "set print object on", uses value_rtti_type and/or
> value_rtti_target_type.
> 
> The patch also has some non-GNU-formatted code; no big deal, just a
> bunch of nits to clean up.
> 
> Richard> It is very similar to valpy_get_type (without what appears to
> Richard> be an unnecessary Py_INCREF).
> 
> The code:
> 
>   value_object *obj = (value_object *) self;
>   if (!obj->type)
>     {
>       obj->type = type_to_type_object (value_type (obj->value));
>       if (!obj->type)
> 	{
> 	  obj->type = Py_None;
> 	  Py_INCREF (obj->type);
> 	}
>     }
>   Py_INCREF (obj->type);
>   return obj->type;
> 
> The first Py_INCREF is there because obj->type must be a new reference
> to an object.  That lets us pair with the decre at object destruction.
> It looks weird, being on Py_None, but I think that is still correct.
> 
> The second Py_INCREF is so that we always return a new reference to our
> caller.
> 
> So, I think they are both needed.  But if not, I definitely want to know
> about it, and why :-)
> 
> Tom
I'll look at the other points later when I have time, but In this case 
if Py_None is used it will be incremented twice before being handed back 
to the caller.

Richard.