This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to add rtti_type member to gdb.Value


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]