This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC/Patch v2] PR 16113: Allow gdb.Field objects as subscripts on gdb.Value objects
- From: Tom Tromey <tromey at redhat dot com>
- To: Siva Chandra <sivachandra at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 10 Dec 2013 14:38:54 -0700
- Subject: Re: [RFC/Patch v2] PR 16113: Allow gdb.Field objects as subscripts on gdb.Value objects
- Authentication-results: sourceware.org; auth=none
- References: <CAGyQ6gzCOh-11do-kSwO9wMb9Ap-zErSdXvbQAVehBc9hTDF+Q at mail dot gmail dot com>
>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:
Siva> + arg = type_to_type_object (type);
Siva> + if (arg == NULL)
Siva> + goto fail;
I think if TYPE is not a gdb.Type then this will return -1 without
setting the Python exception.
Siva> + parent_type = type_object_to_type (type_object);
Siva> + Py_DECREF (type_object);
Siva> + if (parent_type == NULL)
Siva> + return -1;
Likewise.
Siva> + if (TYPE_CODE (val_type) == TYPE_CODE_STRUCT
Siva> + && types_equal (val_type, parent_type))
Siva> + has_field = 1;
What about TYPE_CODE_UNION and TYPE_CODE_RANGE?
Offhand I don't recall if other types present "fields".
Maybe TYPE_CODE_FUNC? TYPE_CODE_COMPLEX?
Siva> + artificial = get_field_flag (key, "artificial");
Siva> + if (artificial < 0)
Siva> + return NULL;
Siva> + else if (artificial > 0)
Siva> + {
Siva> + PyErr_SetString (PyExc_ValueError,
Siva> + _("Cannot lookup artificial fields."));
Siva> + return NULL;
Siva> + }
Is there a reason for this?
It seems to me that it is ok to do this.
Siva> + else if (base_class_type_object)
We use "!= NULL" now.
Tom