From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9266 invoked by alias); 18 Sep 2010 20:28:01 -0000 Received: (qmail 9257 invoked by uid 22791); 18 Sep 2010 20:28:01 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out2.tiscali.nl (HELO smtp-out2.tiscali.nl) (195.241.79.177) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 18 Sep 2010 20:27:55 +0000 Received: from [212.123.169.34] (helo=[192.168.1.102]) by smtp-out2.tiscali.nl with esmtp (Exim) (envelope-from ) id 1Ox40n-0007Bx-6e; Sat, 18 Sep 2010 22:27:53 +0200 Subject: Re: [PATCH] [RFC] python: gdb.Type: strip typedefs past pointers too From: Paul Bolle To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20100918141253.GM3845@adacore.com> References: <1284753356.21566.10.camel@localhost.localdomain> <20100918141253.GM3845@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 19 Sep 2010 17:56:00 -0000 Message-ID: <1284841648.1857.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-09/txt/msg00331.txt.bz2 On Sat, 2010-09-18 at 10:12 -0400, Joel Brobecker wrote: > Personally, I think that the current behavior is correct. But I did > not participate in the design of the API, so others will probably > have a more informed opinion. > > If we want to support the behavior you are looking for, I think it > should be done either through the control of a parameter (defaulted > to current behavior), or another method (recursive_strip_typedef). The documentation reads: > -- Method on Type: strip_typedefs > Return a new `gdb.Type' that represents the real type, after > removing all layers of typedefs. I feel that both the name of this function (which uses typedefs in plural) and the documentation imply the behavior my patch tries to achieve. > Small nit on the coding style: the `||' should be at the beginning > of the next line: This nit (and the later one) I'll try to remember. > (how about references?) I have no idea. References are C++ things, aren't they? Paul Bolle