diff options
author | Andrew Burgess <aburgess@redhat.com> | 2024-11-10 15:50:26 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-11-14 19:34:44 +0000 |
commit | ad39b4aae84a224dc5451d6a5f707b1db67a7b7e (patch) | |
tree | ba5c21256f770093040370fd7f61285f0f45b395 /gdb/python/py-newobjfileevent.c | |
parent | 5209b83f530fad1598db3eeb406762bf3fa3d5d2 (diff) | |
download | gdb-ad39b4aae84a224dc5451d6a5f707b1db67a7b7e.zip gdb-ad39b4aae84a224dc5451d6a5f707b1db67a7b7e.tar.gz gdb-ad39b4aae84a224dc5451d6a5f707b1db67a7b7e.tar.bz2 |
gdb/python: missing PyObject_IsTrue error check in micmdpy_set_installed
Like the previous commit, I discovered that in micmdpy_set_installed
we were calling PyObject_IsTrue, but not checking for a possible error
value being returned.
The micmdpy_set_installed function implements the
gdb.MICommand.installed attribute, and the documentation indicates that
this attribute should only be assigned a bool:
This attribute is read-write, setting this attribute to 'False'
will uninstall the command, removing it from the set of available
commands. Setting this attribute to 'True' will install the
command for use.
So I propose that instead of using PyObject_IsTrue we use
PyBool_Check, and if the new value fails this check we raise an
error. We can then compare the new value to Py_True directly instead
of calling PyObject_IsTrue.
This is a potentially breaking change to the Python API, but hopefully
this will not impact too many people, and the fix is pretty
easy (switch to using a bool). I've added a NEWS entry to draw
attention to this change.
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python/py-newobjfileevent.c')
0 files changed, 0 insertions, 0 deletions