From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6dXGOvAUmWkOfgMAWB0awg (envelope-from ) for ; Fri, 20 Feb 2026 21:14:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1771640048; bh=YkHZ9J2oDhJPw1wQyh41c1APdyahn0FejRMtPReO4lo=; h=Date:Subject:From:To:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=aglDU8vh+WECcLVjLpfmGvakLJYZuXvjHiv3eyMgmqta6M0fCqTQCy7O3qFK518gW izNK1Rdjlp9b1wBdZ5zh8wAqTwULQdsItG+VTjVBfuldYCWKQpXnkbSw2ZndyurWZy zNAocUIDT/Dy7U2hsnHUV08iGOVsA44C9y32BQwg= Received: by simark.ca (Postfix, from userid 112) id D6DFC1E0BA; Fri, 20 Feb 2026 21:14:08 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Q97xk66r; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A630E1E08D for ; Fri, 20 Feb 2026 21:14:07 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id F1C474BAD143 for ; Sat, 21 Feb 2026 02:14:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1C474BAD143 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Q97xk66r Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id AFDBC4B9DB66 for ; Sat, 21 Feb 2026 02:13:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AFDBC4B9DB66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AFDBC4B9DB66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771640021; cv=none; b=IcWIia5RfFGXSV1ACNYH5Qgt2JvG3pNa6NagXcJZxayORo2ZZqgDm16yNHINLw4rF6mENIxmwEcoxqdvDaOKUCWDFfHZ+V/5ArrCzvCK/XD0A3IHZ66IFKwIJLe+K9lYHrKO/nkMIaxiSmyFxGqsjtje8JZM44xMl/tDO8uv4A4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771640021; c=relaxed/simple; bh=YkHZ9J2oDhJPw1wQyh41c1APdyahn0FejRMtPReO4lo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=mtJfrzUwGtdAdd7/o7lWlOq19rd+jcBU0eym7/B2ViAZgft/aJQY1lUMqnyaGMIzYRvH7GVCOY+Sg19FT1f0nrK+57I/jFz2JR1y+ZtQNI94AQT4mxj0bAQhr1YEinIL60HM7E1+0Lt/ZPEY+HBsKJWiC7we9H/zkiJSroV4t7Q= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFDBC4B9DB66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1771640021; bh=YkHZ9J2oDhJPw1wQyh41c1APdyahn0FejRMtPReO4lo=; h=Date:Subject:From:To:References:In-Reply-To:From; b=Q97xk66rz7JkVjN879g2odmJN1HmTVs7VFvNQLEWiUzRzCpQNr8tMGfugPRxm286K IwXo0xFc07dbYIMfLK3tVHW8+5vp1HMNwlM4SHR1mbfSwpxAvaG+C46EXa/kIVpGdG S4Er/9ovjqT/B6K+1reXbYZfmFjEu8E03qIUwnVE= Received: by simark.ca (Postfix) id DA30F1E08D; Fri, 20 Feb 2026 21:13:40 -0500 (EST) Message-ID: <2bd802a4-75e2-4af9-90c9-d9ff89163a9a@simark.ca> Date: Fri, 20 Feb 2026 21:13:40 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/10] Return gdbpy_ref<> from symtab_and_line_to_sal_object From: Simon Marchi To: Tom Tromey , gdb-patches@sourceware.org References: <20260220-python-safety-minor-v1-0-4c4b12e445af@adacore.com> <20260220-python-safety-minor-v1-1-4c4b12e445af@adacore.com> <9eed1009-8563-45cf-b9d2-e0ebb3005683@simark.ca> Content-Language: en-US In-Reply-To: <9eed1009-8563-45cf-b9d2-e0ebb3005683@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-02-20 20:58, Simon Marchi wrote: > > > On 2026-02-20 16:03, Tom Tromey wrote: >> This changes symtab_and_line_to_sal_object to return a gdbpy_ref<>, >> using the type system to convey that a new reference is always >> returned. > > I noted some stylistic suggestions below. It's a bit subjective so it's > up to you really. I suppose that the same patterns happen in all the > patches. > >> @@ -560,7 +560,7 @@ pspy_find_pc_line (PyObject *o, PyObject *args) >> return gdbpy_handle_gdb_exception (nullptr, except); >> } >> >> - return result; >> + return result.release (); > > In these cases I think I would return directly from the > symtab_and_line_to_sal_object call: > > return symtab_and_line_to_sal_object (sal).release (); > >> diff --git a/gdb/python/py-symtab.c b/gdb/python/py-symtab.c >> index 2dca0083277..820542932ba 100644 >> --- a/gdb/python/py-symtab.c >> +++ b/gdb/python/py-symtab.c >> @@ -390,7 +390,7 @@ symtab_to_symtab_object (struct symtab *symtab) >> >> /* Create a new symtab and line (gdb.Symtab_and_line) object >> that encapsulates the symtab_and_line structure from GDB. */ >> -PyObject * >> +gdbpy_ref<> >> symtab_and_line_to_sal_object (struct symtab_and_line sal) >> { >> sal_object *sal_obj; >> @@ -399,7 +399,7 @@ symtab_and_line_to_sal_object (struct symtab_and_line sal) >> if (sal_obj != nullptr) >> set_sal (sal_obj, sal); >> >> - return (PyObject *) sal_obj; >> + return gdbpy_ref<> (sal_obj); > > I think you could be even more pedantic and change sal_obj to be of type > gdbpy_ref<>. This way, the ref is managed from the very edge of the > Python API. Regarding this, I thought this would work, but it doesn't: gdbpy_ref sal_obj (PyObject_New (sal_object, &sal_object_type)); if (sal_obj != nullptr) set_sal (sal_obj.get (), sal); return sal_obj; I don't know if there is a magic way to make gdbpy_ref implicitly convertible to gdbpy_ref<>. I tried changing the return type of symtab_and_line_to_sal_object to be gdbpy_ref instead. I don't think it would be a bad thing, it would convey what type of object it is exactly. But this would require moving the definition of struct sal_object in some header file, otherwise the other files don't know that `sal_object *` is convertible to `PyObject *`, when they try to pass the released value to the Python API. Anyway, what you have here is fine, it is definitely an improvement over the current state. Simon