From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id E933A384D19A for ; Wed, 29 Jun 2022 16:48:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E933A384D19A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x429.google.com with SMTP id d17so17709226wrc.10 for ; Wed, 29 Jun 2022 09:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=gsipfys2K24LzmjRr5RXizqbiEaVk87h72RRrP+/vog=; b=Wf2LFSJBnzXJMiXzDG+N9kdPzThlXsfkb62cRerG05lBA2zDm8fXZhLBmxkqpwGywu OlHonkqhQbBbpR4GFDGxdCTg3pCRGxxqJClKq0Fs1MNuJotllLCY3MBGSA8gTra+BVFY dP/fkEhf9zGlY2+cFr7XQFAkrQjVQXvka4EGgksDie5+B1/XUBTvul9Efa1P3sG6RsKk +a6F0GhLsnMZ64hAW5NLIKzaGF2GzakO1QhkDx4cV7i/0u9vUrLYiME6kb+xuq6wZxKs l9UUmfY388fVqZRZ2J4TJtdq2JOILKX2isBMkoz3mRbTCQ0knbJ8i6FD+wBFQUW0CQ7H Yb7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=gsipfys2K24LzmjRr5RXizqbiEaVk87h72RRrP+/vog=; b=YUlPtzzK3O6EYBe+xKjxOAzytXoKio0k7km2MzCncxrpF/lgUR2Odl2T06AI6jDjAZ b/ClX23//4Gt88o5JMA05IAT+ivnzQPkHna1iCVYjzEOOkOopc2i2hiEd7ZNPPX4wsF4 XLEg4qoZhG1yle35et43uWgkhkYOAJahoArF1kPlAYTRCbJdLYC0h9LzyFSEZ4BmgxMG LNmYUlIQVb3UjIuMYj4KaWSy04VdqKNCXAVwMAnbEnHWQ+xVBiWXstfjM0LIy+yGEq88 cmeRjdE5ZIY0iUlqlQnfki7Gf7Six5OcIQNfTD5hpfhSiMV4p3pzDKf6rVKAagA36QMh GYHA== X-Gm-Message-State: AJIora94ctd5tH8cNnOmDkWBVewAHQSbaSLV3k/dKatsqUcEnMbtW8zX DZd5DIVUrKAsJoHhi1II0TL5nQ== X-Google-Smtp-Source: AGRyM1tVkeDWKTJh01Iy4i47CjqBzt9UMU6YlVB0s4M46wcLDjXsQtn1epXqZRHRLub7w3dVDA9qHQ== X-Received: by 2002:adf:dd84:0:b0:21b:88da:c755 with SMTP id x4-20020adfdd84000000b0021b88dac755mr4172201wrl.495.1656521295661; Wed, 29 Jun 2022 09:48:15 -0700 (PDT) Received: from tpp.orcam.me.uk (tpp.orcam.me.uk. [2001:8b0:154:0:ea6a:64ff:fe24:f2fc]) by smtp.gmail.com with ESMTPSA id k12-20020a7bc30c000000b0039c673952bfsm3911062wmj.6.2022.06.29.09.48.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jun 2022 09:48:14 -0700 (PDT) Date: Wed, 29 Jun 2022 17:48:13 +0100 (BST) From: "Maciej W. Rozycki" To: Andrew Burgess cc: gdb-patches@sourceware.org, Simon Sobisch , Tom Tromey Subject: Re: [PATCH v5 2/8] GDB/Python: Use None for `var_zuinteger_unlimited' value set to `unlimited' In-Reply-To: <877d56azv6.fsf@redhat.com> Message-ID: References: <877d56azv6.fsf@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2022 16:48:18 -0000 On Fri, 24 Jun 2022, Andrew Burgess wrote: > > Consistently with the `var_integer' and `var_uinteger' parameters return > > the special value of None for a `var_zuinteger_unlimited' parameter set > > to `unlimited' by using the Py_RETURN_NONE macro in this case, fixing > > commit 0489430a0e1a ("Handle var_zuinteger and var_zuinteger_unlimited > > from Python"); cf. PR python/20084. Adjust the testsuite > > accordingly. > > Unfortunately, nice as it would be to make this change (for > consistency), I think we're stuck with what we have. Yes, this does seem a bit risky, however we already have a documented precedent for a similar API correction: -- Function: gdb.breakpoints () Return a sequence holding all of GDB's breakpoints. *Note Breakpoints In Python::, for more information. In GDB version 7.11 and earlier, this function returned 'None' if there were no breakpoints. This peculiarity was subsequently fixed, and now 'gdb.breakpoints' returns an empty sequence in this case. and here the peculiarity/inconsistency in my opinion is even more prominent. > The -1 behaviour is documented for PARAM_ZUINTEGER_UNLIMITED in the > manual so it is not unreasonable to assume that there could be code in > the wild that relies on the existing behaviuor. Well, but that is not different from the two other cases, which have no mention of 'None': 'gdb.PARAM_UINTEGER' The value is an unsigned integer. The value of 0 should be interpreted to mean "unlimited". 'gdb.PARAM_INTEGER' The value is a signed integer. The value of 0 should be interpreted to mean "unlimited". even they do return 'None' for "unlimited", and then as you say: 'gdb.PARAM_ZUINTEGER_UNLIMITED' The value is a signed integer. This is like 'PARAM_ZUINTEGER', except the special value -1 should be interpreted to mean "unlimited". Other negative values are not allowed. So what I think would be best to do here is actually (having missed the manual part before): 1. Accept (if we don't already; I haven't checked) and document 'None' as input to parameters of these types, meaning "unlimited". 2. Deprecate and undocument but keep accepting special numeric values as input to such parameters. 3. Produce and document 'None' as output for special "unlimited" numeric values consistently from all such parameters. Yes, there could be some fallout from such a change, however it should be easy to correct in Python code. What would be a typical use case in Python code for retrieving these parameters? And how is 'None' handled by Python when just passed to a `print' like standard routine to present it to the user? Given that PARAM_ZUINTEGER_UNLIMITED has been retrofitted chances are its handling in user code has been as well to existing code for PARAM_UINTEGER and PARAM_INTEGER, and it may already handle 'None' for all the three by default, before going on to special-casing the special values actually documented. Please let me know what you think, and thank you for your review. Maciej