This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v4] gdb/python: add missing handling for anonymous members of struct and union
- From: Paul Koning <paulkoning at comcast dot net>
- To: gdb-patches at sourceware dot org, Phil Muldoon <pmuldoon at redhat dot com>, Li Yu <raise dot sail at gmail dot com>
- Date: Tue, 18 Oct 2011 15:03:28 -0400
- Subject: Re: [PATCH v4] gdb/python: add missing handling for anonymous members of struct and union
- References: <CA+WLrf-MM2WPr6r8DLKcZP5-A6qmZst8Sxzy4u5OvrxFET5sEQ@mail.gmail.com> <email@example.com> <09787EF419216C41A903FD14EE5506DD030CB90864@AUSX7MCPC103.AMER.DELL.COM>
On Oct 18, 2011, at 10:21 AM, <Paul_Koning@Dell.com> wrote:
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Phil Muldoon
> Sent: Tuesday, October 18, 2011 9:58 AM
> To: Li Yu
> Cc: firstname.lastname@example.org; Paul Koning; Tom Tromey
> Subject: Re: [PATCH v4] gdb/python: add missing handling for anonymous members of struct and union
> Li Yu <email@example.com> writes:
>> gdb.Type.fields() missed handling for anonymous members.
>> This patch fix it, below are details:
> Sorry I missed this patch. I have some questions.
> Given this functionality, do you have any use-cases in mind for it? Do we really want to include anonymous members in field () output? I ask because I cannot decide if the additional anonymous field information constitutes an API break. If so we may have to reconstitute this functionality from fields() so that it takes a keyword to turn this behavior on and off.
I raised a related question two weeks ago: http://sourceware.org/ml/gdb-patches/2011-10/msg00118.html .
It would seem logical for things to be consistent. That's quite a lot more work than this one patch, but it can certainly be handled as a collection of independent changes.
Another possible approach is to leave gdb.Type.fields() alone, but supply a little bit of Python code for the gdb python library that implements a recursive iterator. It's quite easy to do that:
def deepitems (t):
for k, v in t.iteritems ():
yield k, v
for i in deepitems (v.type):