Re: [RFC 1/4] Add gdbpy_borrowed_ref

[Simon Marchi <simark@simark.ca>]

On 2026-02-24 22:55, Tom Tromey wrote:
>>> +  template<typename T,
>>> +	   typename = std::is_convertible<T *, PyObject *>>
>>> +  operator T * ()
>>> +  {
>>> +    gdb_assert (PyObject_TypeCheck (m_obj, T::corresponding_object_type));
>>> +    return static_cast<T *> (m_obj);
>>> +  }
> 
> Simon> Shouldn't gdbpy_borrowed_ref be templated?  Allowing any gdbpy_ref to be
> Simon> downcast to any subclass of PyObject seems a bit permissive.  At least
> Simon> there is a runtime check, but it would be nice to have more type safety
> Simon> at compile time.
> 
> Yeah, however this does not actually come up very much.
> 
> In fact all the casts I am aware are of 'self', which means we could
> maybe solve this a special case: turn functions into methods on the
> object, and then have the wrappers wrap a pointer-to-member-function.
> 
> This would mean that 'this' would be implicitly a borrowed reference,
> but OTOH this isn't likely to be a big source of confusion and it would
> make the code even simpler.
> 
> Simon>   arch_object *arch = gdbpy_borrowed_ref<arch_object> (...);  // works
> Simon>   arch_object *arch = gdbpy_borrowed_ref<PyObject> (...);  // does not work
> 
> Simon> That being said, apart from the wrappers themselves, I don't expect that
> Simon> we'll need to do that often.  I suppose that it would be possible to
> Simon> access the fields like this?
> 
> As long as there's an operator*.  But if we did the method approach,
> there'd be basically no need for this at all.
> 
> Simon> I also toyed with defining some types like:
> 
> Simon> struct PyDict : public PyObject {};
> Simon> struct PyList : public PyObject {};
> Simon> struct PyLong : public PyObject {};
> Simon> struct PyTuple : public PyObject {};
> Simon> struct PyType : public PyObject {};
> 
> Simon> gdbpy_new_list would return a gdbpy_ref<PyList>.
> Simon> gdbpy_list_append would take a gdbpy_borrowed_ref<PyList>.
> 
> Simon> And then we could have some ways of down-casting, if needed.
> 
> It could be done.  I'm ambivalent about it since I don't think this is a
> common source of errors in gdb, I guess mainly because the needed
> type-checks are re-done by Python anyway.
> 
> OTOH we've had multiple refcount bugs and multiple cases where exception
> checks are missed.  Those are the problems I really set out to solve.

Ack.  I agree it's fine to go for that, at least at first.

Simon