From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0RKzGIxUqGo40gwAWB0awg (envelope-from ) for ; Mon, 14 Sep 2026 16:09:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789416588; bh=cO+lad6A8HSM6xNw6S/02FssXrF8tGj/FXRNuzlQ60Y=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=qq55JoW2aXL1I44f7ujZ8QSNWhhrLRtUP5pEcAgs5YPnOBYAm2KKEwnKNhslEwE3b GUTidhPjBDVvVC1WwZuZ8v0eerO1yebgMrBQjYGoQXT0Vn/F7HSoI6HCjlC9bkeKFp akxQ1E/hLc5AjEutI/g2U+8vCwwOk/LzxBuvBIaI= Received: by simark.ca (Postfix, from userid 112) id 505FA1E06B; Mon, 14 Sep 2026 16:09:48 -0400 (EDT) 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=m7luv0cS; 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 9D7C31E051 for ; Mon, 14 Sep 2026 16:09:47 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 30F8A4B99F66 for ; Mon, 14 Sep 2026 20:09:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 30F8A4B99F66 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=m7luv0cS Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 5F7F54BAE7E6 for ; Mon, 14 Sep 2026 20:09:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F7F54BAE7E6 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 5F7F54BAE7E6 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789416563; cv=none; b=sQaaCgspgvDm6Y5n6JH6na+UyptjNDf0bgvBwkIiMKGt5m2u59MLSkST/i4+ms8SszJSCn6TXye8zGTvOgnLY/K4cQ+4LrKKjDu85qT6v/OQBwV0ufXiagPnLwi4oBGgVuUhObbqagzDalsdYcm2tJXFdUlgY+tYjR/AG/MKwk4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789416563; c=relaxed/simple; bh=cO+lad6A8HSM6xNw6S/02FssXrF8tGj/FXRNuzlQ60Y=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JAyxBKOY6/N2QdRCehF43JE5dkqwvdI6k9ZAw/wIAC85d6f43lOy2wlb3OrZubMupc1w3cCcbiKjvnKeY9MRtKM7h6Mdiz0KP+y+1m9sL8WrCbM3qKz7BStnPovvn8TFijcXkigbyhJ3ni3KInhL8ridc2nKxagfjSmArg4d7NY= ARC-Authentication-Results: i=1; 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=m7luv0cS DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5F7F54BAE7E6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789416561; bh=cO+lad6A8HSM6xNw6S/02FssXrF8tGj/FXRNuzlQ60Y=; h=Date:Subject:To:References:From:In-Reply-To:From; b=m7luv0cSvKtV+O4TYD8lIvfA1vEiilaQOoxcqBTWyQBLvFndsuc5Zdq/LVbPMFgEb cDP/iW3Gm6VJI9msnYF2cvrJJIxr0rqtsvOJmW1HfSyNdMiNlzyOMgk4RvzSAibdI1 ZNc/4DB8YQ7PwTvqjyyzG/TsE/Ug+z5XaurxIQUM= Received: by simark.ca (Postfix) id EA7A41E051; Mon, 14 Sep 2026 16:09:20 -0400 (EDT) Message-ID: <7288831a-098e-486d-8c02-088a2e1affc3@simark.ca> Date: Mon, 14 Sep 2026 16:09:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Wrap (and poison) PyObject_CallFunctionObjArgs To: Tom Tromey , gdb-patches@sourceware.org References: <20260914190624.4178522-1-tom@tromey.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260914190624.4178522-1-tom@tromey.com> 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 9/14/26 3:06 PM, Tom Tromey wrote: > This patch adds a new wrapper for PyObject_CallFunctionObjArgs. The > wrapper function knows how to unwrap gdbpy_ref<> and > gdbpy_borrowed_ref<>. It rejects null arguments, and it automatically > supplies the trailing NULL required by PyObject_CallFunctionObjArgs. > Finally, PyObject_CallFunctionObjArgs is poisoned to avoid introducing > new calls. > > The idea behind this change is that passing anything other than > PyObject* to this function will cause failures; this patch turns > silent failures (like passing a gdbpy_borrowed_ref<>) into a > compile-time failure. LGTM, see minor comments below. Approved-By: Simon Marchi > +/* A wrapper for PyObject_CallFunctionObjArgs that takes various kinds > + of gdb wrappers, in addition to "PyObject *". This variant does > + not allow NULL arguments. While PyObject_CallFunctionObjArgs > + requires a trailing NULL, this function does not -- it supplies the > + required trailing NULL on its own. > + > + As a safety measure, no argument may be NULL. While this may be > + slightly inconvenient at times (you can't early-terminate the > + arguments, you have to add a special case at the call site), it > + avoids bugs where early termination was unintentional. */ I think it's fine. One example is in evpy_emit_event, and I find the new code clearer, because it's more explicit about the two possibilities. > +template > +static inline gdbpy_ref<> > +gdbpy_object_call_function_obj_args (Arg &&fn, Args && ...args) > +{ > + PyObject *result > + = PyObject_CallFunctionObjArgs (detail::unwrap_ref (fn), > + detail::unwrap_ref (args)..., > + nullptr); > + return gdbpy_ref<> (result); > +} > + > +/* Poison PyObject_CallFunctionObjArgs. The typesafe wrapper > + gdbpy_objects_call_function_obj_args should be used instead. */ Typo, gdbpy_objects_call_function_obj_ar -> gdbpy_object_call_function_obj_args > +#undef PyObject_CallFunctionObjArgs > +#ifdef __GNUC__ > +# pragma GCC poison PyObject_CallFunctionObjArgs > +#else > +# define PyObject_CallFunctionObjArgs POISONED_PyObject_CallFunctionObjArgs > +#endif Clang appears to support "pragma GCC poison", could we use it unconditionnaly? Simon