From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22461 invoked by alias); 1 Oct 2011 18:54:45 -0000 Received: (qmail 22453 invoked by uid 22791); 1 Oct 2011 18:54:44 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta06.westchester.pa.mail.comcast.net (HELO qmta06.westchester.pa.mail.comcast.net) (76.96.62.56) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 01 Oct 2011 18:54:30 +0000 Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id fWEt1h0031ap0As56WuX0y; Sat, 01 Oct 2011 18:54:31 +0000 Received: from [192.168.10.125] ([75.68.58.5]) by omta22.westchester.pa.mail.comcast.net with comcast id fWuW1h00206m2QB3iWuWiw; Sat, 01 Oct 2011 18:54:30 +0000 Subject: Re: [PATCH v2] gdb/python: add missing handling for anonymous members of struct and union Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Sat, 01 Oct 2011 18:54:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <717C3E72-CC23-4894-963D-F74D4A72A8E5@comcast.net> References: <4E8595F6.7080004@gmail.com> <07654BC2-7955-4858-8AE9-CA9FF895A158@comcast.net> To: Li Yu 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: 2011-10/txt/msg00012.txt.bz2 On Oct 1, 2011, at 10:01 AM, Li Yu wrote: > 2011/9/30 Paul Koning : >>=20 >> On Sep 30, 2011, at 6:12 AM, Li Yu wrote: >>=20 >>> ... >>=20 >> That whole chunk of code would be simpler and probably easier to underst= and if you wrote it as a recursion rather than a loop. Something like: >>=20 >> restart: >> if (iter_obj->child) >> { >> result =3D typy_iterator_iternext (iter_obj->child); >> if (result !=3D NULL) >> return result; >> Py_CLEAR (iter_obj->child); >> } >> ... >> If you use recursion, all this simply becomes Py_CLEAN (iter_obj->child); >>=20 >=20 > I indeed do not like use recursion in any production code, because of it = implies > some problems, e.g. it may bring more function calls at runtime, which > means much > security risk and may use more memory, en, this just is my personal taste. >=20 > Of course, you must have more experience on gdb internals, if you decide = to use > recursion here, I will agree with you too and would like write a > recursion implementation later. I'm not all that experienced on gdb internals. But, for example, you can s= ee that the standard "ptype" command uses recursion. If it's ok for regula= r gdb commands, it should be ok for this case. The amount of stack space u= sed isn't that high since the stack frames for the functions in question ar= e pretty small. >=20 > I will leave about one week, see you later ~ >=20 >>> return NULL; >>> } >>=20 >> You need to free iter_obj->child in the iterator destructor. >>=20 >=20 > I think that Py_DEFREF(iter_obj->child) should be able to help us > reclaim our allocated iterators here. What I meant is that you don't have that code in typy_iterator_dealloc.=20 paul