This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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] |
On Mon, Jul 4, 2011 at 2:13 AM, Phil Muldoon <pmuldoon@redhat.com> wrote: > Matt Rice <ratmice@gmail.com> writes: > >> Thanks, attached is an updated patch that also includes tests. > > Thanks. > >> + ? ? ?ret_tuple = PyTuple_New (2); >> + ? ? ?if (!ret_tuple) >> + ? ? ? ?return Py_None; > > Return NULL here. ?This signifies an error, and that we have abandoned > the function. ?When a Python function returns NULL, the exception is > eventually printed and cleared either by the callers, or by the GDB > Python top-level exception handling code. Thanks for explaining, that is what I wanted. You said so in your first email, but for some reason it didn't latch on, sorry. >> + ? ? ?start = gdb_py_long_from_ulongest (start_pc); >> + ? ? ?if (!start) >> + ? ? goto fail_ret; >> + ? ? ?if (PyTuple_SetItem (ret_tuple, 0, start) != 0) >> + ? ? { >> + ? ? ? Py_XDECREF (start); >> + ? ? ? goto fail_ret; >> + ? ? } > > You do not need to decrement "start" here. ?Even if the tuple SetItem > call failed, you have already passed the responsibility to the tuple, > and you no longer own it (stolen reference). ?SetItem would decrement > this on failure. ?So just goto to your local error block. OK, the docs were silent on this regard, and I guessed on error it wouldn't steal it. >> + ? ? ?end = gdb_py_long_from_ulongest (end_pc); >> + ? ? ?if (!end) >> + ? ? goto fail_ret; >> + ? ? ?if (PyTuple_SetItem (ret_tuple, 1, end) != 0) >> + ? ? { >> + ? ? ? Py_XDECREF (end); >> + ? ? ? goto fail_ret; >> + ? ? } > > Same as above. > >> + ? ? ?fail_ret: >> + ? ? ? ?Py_XDECREF (ret_tuple); > > Small nit, and this is generally ok, but you already know that if this > error block is called, ret_tuple will be instantiated. So in this case > the XDECREF is a tiny bit redundant. ?You could just use DECREF here and > skip the NULL check that XDECREF does. ?Like I said, a tiny nit, but I > just thought I would point it out. k. >> + ? ? return Py_None; > > If there is a Python exception that you cannot handle internally to your > function, you must always return NULL. ?This informs callers, and > ultimately the exception managing code in GDB that some Python call > failed, to print the exception, and clear it. > >> @@ -526,6 +573,8 @@ static PyMethodDef sal_object_methods[] = { >> ? ?{ "is_valid", salpy_is_valid, METH_NOARGS, >> ? ? ?"is_valid () -> Boolean.\n\ >> ?Return true if this symbol table and line is valid, false if not." }, >> + ?{ "find_line_pc_range", salpy_find_line_pc_range, METH_NOARGS, >> + ? ?"Return a tuple of start and end ranges for the symbol table." }, >> ? ?{NULL} ?/* Sentinel */ >> ?}; > > We try to put the return type in the help now as a formal statement. > Look at the two-line help example above: "is_valid()" for guidance. Updated that text a little bit also, along with using Eli's text for the manual. 2011-07-04 Matt Rice <ratmice@gmail.com> * python/py-symtab.c: Populate sal_object_methods. (salpy_find_line_pc_range): New function. 2011-07-04 Matt Rice <ratmice@gmail.com> Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Symbol Tables In Python): Add find_line_pc_range method. 2011-07-04 Matt Rice <ratmice@gmail.com> * gdb.python/py-symtab.exp: New Tests for find_line_pc_range.
Attachment:
foo.diff
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |