This is the mail archive of the
mailing list for the Archer project.
Re: Patch to add rtti_type member to gdb.Value
- From: Tom Tromey <tromey at redhat dot com>
- To: Richard Ward <richard dot j dot ward1 at googlemail dot com>
- Cc: archer at sourceware dot org
- Date: Fri, 25 Sep 2009 13:03:31 -0600
- Subject: Re: Patch to add rtti_type member to gdb.Value
- References: <4ABA6ADD.firstname.lastname@example.org>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Richard" == Richard Ward <email@example.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
Is that always the case? I ask because other code, like the code
implementing "set print object on", uses value_rtti_type and/or
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).
value_object *obj = (value_object *) self;
obj->type = type_to_type_object (value_type (obj->value));
obj->type = Py_None;
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
So, I think they are both needed. But if not, I definitely want to know
about it, and why :-)