Re: [RFC 0/4] Better Python safety

[Simon Marchi <simark@simark.ca>]

On 2026-02-22 14:49, Tom Tromey wrote:
> This series is a rough draft showing how I think Python safety could
> be improved.
> 
> The basic idea is to use C++ features: more fully use gdbpy_ref<> to
> avoid reference-counting bugs, introduce a new gdbpy_borrowed_ref to
> manage borrowed references; throw exceptions on failure rather than
> explicit error checks; and finally wrap Python C APIs to enforce these
> rules.
> 
> This approach also lets us implement Python methods in a more natural
> style.  Explicit try/catch when calling gdb APIs is no longer needed,
> and methods can simply return the appropriate type.
> 
> This series is nowhere near complete, but I did mostly convert
> py-arch.c and py-frame.c.  (Discussion of some holes below.)
> 
> A nice example of the simplification is shown by
> gdbpy_all_architecture_names, which is now just:
> 
> gdbpy_ref<>
> gdbpy_all_architecture_names (gdbpy_borrowed_ref self)
> {
>   gdbpy_ref<> list = gdbpy_new_list (0);
> 
>   std::vector<const char *> name_list = gdbarch_printable_names ();
>   for (const char *name : name_list)
>     gdbpy_list_append (list, gdbpy_unicode_from_string (name));
> 
>  return list;
> }
> 
> This shows pretty much all the features: no more error checking and it
> returns a gdbpy_ref<> since that is convenient.
> 
> 
> I think a few more features could still be added:
> 
> * I didn't handle single-argument methods in patch 3.  It's tempting
>   to use METH_O but we have at least one that accepts "|s".
> 
> * I didn't write wrappers for tp_str / tp_repr ... or the methods in
>   PyNumberMethods or PyMappingMethods.  This isn't difficult.
> 
> * I think the approach to handling subclasses of PyObject could be
>   greatly improved.  In particular I think we could use real C++
>   classes by judicious use of placement new and explicit destructor
>   calls.  The "corresponding_object_type" stuff you'll see in here is
>   sort of a gesture in this direction (though that code also helps
>   with some type-safety elsewhere as well).  Essentially I think we
>   could end up making new instances with just 'new'.
> 
>   I didn't want to really touch this until the stable ABI work related
>   to type-instantiation is done.
> 
> * Finally gdb is using PyObject_New a lot but my reading while
>   researching this series indicates that this is wrong.  However the
>   wrongness is still (I guess temporarily) preserved in a wrapper in
>   this series.
> 
> * There are some comments in the code where I didn't fully convert
>   something.  This would just be a temporary state.
> 
> Let me know what you think.
> 
> Tom
> 

The series doesn't seem to apply well, and it doesn't specify a base
commit.  What commit is this based on?  Alternatively, can you share
your branch directly?

Thanks,

Simon