This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] gdb/python: add missing handling for anonymous members of struct and union
- From: Paul Koning <paulkoning at comcast dot net>
- To: Li Yu <raise dot sail at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 1 Oct 2011 14:54:30 -0400
- Subject: Re: [PATCH v2] gdb/python: add missing handling for anonymous members of struct and union
- References: <4E8595F6.7080004@gmail.com> <07654BC2-7955-4858-8AE9-CA9FF895A158@comcast.net> <CA+WLrf9+HLcN6-zFXx_=WW9AKrw4rHJ1sAZvpYWzs-Mz5rtC0Q@mail.gmail.com>
On Oct 1, 2011, at 10:01 AM, Li Yu wrote:
> 2011/9/30 Paul Koning <paulkoning@comcast.net>:
>>
>> On Sep 30, 2011, at 6:12 AM, Li Yu wrote:
>>
>>> ...
>>
>> That whole chunk of code would be simpler and probably easier to understand if you wrote it as a recursion rather than a loop. Something like:
>>
>> restart:
>> if (iter_obj->child)
>> {
>> result = typy_iterator_iternext (iter_obj->child);
>> if (result != NULL)
>> return result;
>> Py_CLEAR (iter_obj->child);
>> }
>> ...
>> If you use recursion, all this simply becomes Py_CLEAN (iter_obj->child);
>>
>
> I indeed do not like use recursion in any production code, because of it implies
> some problems, e.g. it may bring more function calls at runtime, which
> means much
> security risk and may use more memory, en, this just is my personal taste.
>
> Of course, you must have more experience on gdb internals, if you decide to use
> recursion here, I will agree with you too and would like write a
> recursion implementation later.
I'm not all that experienced on gdb internals. But, for example, you can see that the standard "ptype" command uses recursion. If it's ok for regular gdb commands, it should be ok for this case. The amount of stack space used isn't that high since the stack frames for the functions in question are pretty small.
>
> I will leave about one week, see you later ~
>
>>> return NULL;
>>> }
>>
>> You need to free iter_obj->child in the iterator destructor.
>>
>
> I think that Py_DEFREF(iter_obj->child) should be able to help us
> reclaim our allocated iterators here.
What I meant is that you don't have that code in typy_iterator_dealloc.
paul