This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Python: raise exception on field-related gdb.Type methods if it's not struct or union
On Nov 8, 2011, at 7:29 PM, Doug Evans wrote:
> On Tue, Nov 8, 2011 at 1:40 PM, Paul Koning <paulkoning@comcast.net> wrote:
>> ...
>> I found the answer to that question with a bit of searching. Attached is a patch that raises an exception (TypeError) for len() and all the field reference methods if the type isn't struct or union.
>
> I wasn't sure using as_number here was kosher. "works for me" if it
> does the job.
Yes, the book (Python Reference) says that if __nonzero__ is defined (which is what this does) then that is used for truth testing, otherwise __len__ is, and if neither is defined then the thing in question is always True.
>
>> Does this need new testcases?
>
> Yeah, I think so.
> Verify "not type" DTRT, and affected operations on scalar types flag
> the right error.
>
> One question I have is: for struct types that have an empty field list
> (say an empty struct), what's the result of "not type". True or
> False? I can argue either way, and I'm not sure what's the best
> answer, long term.
> [But then again, my python fu isn't enough to be comfortable with any
> conclusion I reach.]
The way I wrote it, a truth test on a gdb.Type object is always True, so the answer to the question is "False". It doesn't matter if the type is scalar, or struct, or for struct whether it has fields or not. The Python Reference says that objects that define neither a nonzero nor a len operation are always True. That applies, for example, to the Python builtin object "type", and since gdb.Type is vaguely like "type" I figured the same behavior should apply.
>
> Thanks very much for doing this!
>
> btw, a couple of nits:
> 1) Please put a blank line between a function's comment and its definition.
> There are several occurrences of this.
Oops, yes, I should have remembered that.
> 2) Can you rename typy_deref? typy_get_struct works for me, I'm sure
> there's a better name.
> "deref" feels confusing, one can deref a pointer to anything, not
> just structs/unions, and
> the function doesn't necessarily do a dereference.
I like the name you mentioned. Will do.
paul