From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32763 invoked by alias); 12 Dec 2013 02:36:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32752 invoked by uid 89); 12 Dec 2013 02:36:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Dec 2013 02:36:23 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBC2aKRP020286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 21:36:20 -0500 Received: from barimba (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBC2aIgE004548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Dec 2013 21:36:19 -0500 From: Tom Tromey To: Siva Chandra Cc: gdb-patches Subject: Re: [RFC/Patch v3] PR 16113: Allow gdb.Field objects as subscripts on gdb.Value objects References: Date: Thu, 12 Dec 2013 02:36:00 -0000 In-Reply-To: (Siva Chandra's message of "Wed, 11 Dec 2013 15:23:36 -0800") Message-ID: <87eh5i23tp.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-12/txt/msg00459.txt.bz2 Tom> What about TYPE_CODE_UNION and TYPE_CODE_RANGE? Tom> Offhand I don't recall if other types present "fields". Tom> Maybe TYPE_CODE_FUNC? TYPE_CODE_COMPLEX? Siva> I missed TYPE_CODE_UNION so I have added it in the attached patch. The Siva> other types do not support the "fields" method. [But, is it a mistake Siva> that we do not support fields for other methods? The documentation Siva> does talk about ranges, functions and methods. At this point, I am Siva> tempted to ask as to why we should "overload" the method "fields" to Siva> return function/method args? Can we bring in a class hierarchy of Siva> types where in gdb.Type exists as a base class, and gdb.TypeStruct, Siva> gdb.TypeFunction etc. are derived from it. That way, we can add Siva> relevant methods to the respective classes. For example, Siva> gdb.TypeFunction will have "args" as a method and not "fields". I Siva> understand the notion of fields is overloaded internally, but we could Siva> make the Python API clearer.] Yeah, I agree, that would be cleaner. Occasionally it's easy to become blind to the issue after working on gdb for a while. Siva> + arg = type_to_type_object (type); Siva> + if (arg == NULL) Siva> + goto fail; Tom> I think if TYPE is not a gdb.Type then this will return -1 without Tom> setting the Python exception. Siva> The above comment is for the change in py-type.c. The variable TYPE in Siva> question here is "struct type" and not gdb.Type. I think Siva> type_to_type_object would return NULL only if PyObject_New called in Siva> it fails. Is an exception not set by PyObject_New on failure? This one is my mistake. I misread that as type_object_to_type. Siva> 2013-12-11 Siva Chandra Reddy Siva> PR 16113: Allow gdb.Field objects with the subscript operator on I don't remember if the regexp catches this form, best to write "PR python/16113" instead. The patch ok with this change, thanks! Tom