Tom Tromey wrote:
>>>>>> "Richard" == Richard Ward <richard.j.ward1@googlemail.com> writes:
> 
> Richard> I'll look at the other points later when I have time, but In this case
> Richard> if Py_None is used it will be incremented twice before being handed
> Richard> back to the caller.
> 
> Yeah -- once for the store to obj->type, and once for the caller.
> The caller needs a new reference, always.
> For obj->type, this lets us call Py_DECREF without checking whether
> obj->type is None.
> 
> Tom

Ah, I missed the inc for the store. Thanks for explaining.

As for if it is always the case that the run time type is stored in the
value struct, the comments say it is (gdb/value.c:140 or there abouts).
The value seems to be determined in valops.c, in value_ind (actually in
the call to value_full_type). So as soon as a pointer is dereferenced
its run time type is stored.

Originally I was calling value_rtti_type in valpy_get_rtti_type but it
seemed sensible to use enclosing_type seeing as it was there. The fact
that you don't know the run time type until a pointer is dereferenced
seemed sensible to me (as the type of a Base* is always a Base*, even if
the thing it points to is actually a Sub). If the value in question is a
reference, the only way I see in python of getting a gdb.Value object
representing the value being referred to by the reference is to take the
address of the reference, and then dereference that (so we still
dereference a pointer and value_rtti_type is still called).

It seems that print object looks at the type before the dereference. I
guess the question is whether the rtti_type attribute of a
pointer/reference gdb.Value should be a pointer/reference to the
rtti_type of the dereferenced object, or the compile time pointer type.
IMO it should be the compile time pointer type, it seems to make more
sense that way.

As for the non GNU coding standards, I think I've fixed that (and the
python inc) in the attached.

Richard.