This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Allow gdb.Values to become callable if appropriate.
- From: Tom Tromey <tromey at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Tue, 20 Jul 2010 16:17:38 -0600
- Subject: Re: [patch] Allow gdb.Values to become callable if appropriate.
- References: <4C442BAA.2020300@redhat.com>
>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
Phil> Here is a little patch that allows gdb.Values to become "callable".
Phil> In this patch, I have limited the ability to call only values where
Phil> the type == TYPE_CODE_FUNC. It is the responsibility of the user to
Phil> cast or dereference appropriately before attempting a call. If the
Phil> type does not resolve to TYPE_CODE_FUNC, then the call will be
Phil> abandoned. There's not too much checking I can do in the function
Phil> beyond what call_function_by_hand already does. If any errors occur
Phil> in the conversion of the arguments, the call will be abandoned.
Phil> Comments?
Looks good.
Phil> +A @code{gdb.Value} that represents a function or a function pointer is a
Phil> +callable Python object.
>From what I can see, your patch explicitly excludes function pointers.
This may be a bit too strict. I think it would be reasonably safe and
easy to accept references (via coerce_ref) and also function pointers
(doing a single dereference inside the new function).
Alternatively, update the documentation.
Phil> + args_count = PyTuple_Size (args);
Phil> + if (args_count > 0)
Phil> + {
Phil> + int i;
Phil> +
Phil> + vargs = alloca (sizeof (struct value *) * args_count);
Extra space after the "=".
Phil> - 0, /*tp_call*/
Phil> + (ternaryfunc) valpy_call, /*tp_call*/
I don't think this cast is necessary.
Tom