From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18807 invoked by alias); 3 Jul 2011 21:13:46 -0000 Received: (qmail 18799 invoked by uid 22791); 3 Jul 2011 21:13:46 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 03 Jul 2011 21:13:29 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p63LDQNY005962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Jul 2011 17:13:26 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p63LDOZr004229; Sun, 3 Jul 2011 17:13:25 -0400 From: Phil Muldoon To: Matt Rice Cc: gdb-patches@sourceware.org Subject: Re: [patch] [python] find_line_pc_range In-Reply-To: (Phil Muldoon's message of "Sun, 03 Jul 2011 17:18:21 +0100") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Mon, 04 Jul 2011 05:38:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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-07/txt/msg00079.txt.bz2 Phil Muldoon writes: > >> + start = gdb_py_long_from_longest (start_pc); >> + end = gdb_py_long_from_longest (end_pc); >> + PyTuple_SET_ITEM (ret_tuple, 0, start); >> + PyTuple_SET_ITEM (ret_tuple, 1, end); >> + } > >> > Also gdb_py_long_from_longest is macro that points to Py > Long_FromUnsignedLongLong. This can also return NULL which indicates a > failure, so similar to above, you need to check the return and return > NULL if one of them fails. If one of them does return NULL, you also > need to appropriately clean-up previous references that were created in > Python. We normally do this by creating a local error: goto. I read this back, and I thought, I need to explain this a little more because of the weird reference stealing behaviour of Python Tuples/Lists. In a "normal" scenario, if you create a Python object, and later on some bit of code fails, you need to decrement that object in your local error block (or later, if the function succeeds). But because Py_Tuple "steals" a reference, it takes ownership of that object, even if the Tuple itself somehow fails. So in the above case, if "start" was added ok, but "end" did not, you do not need to decrement "start", just decrement the tuple. I think this is one of two Python APIs that does this, so you don't come across it often. Cheers, Phil