From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 32C6E385DC09 for ; Mon, 31 Oct 2022 13:32:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 32C6E385DC09 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-x431.google.com with SMTP id l14so16020896wrw.2 for ; Mon, 31 Oct 2022 06:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=HGdkZv/QYmPpRWqwdaGtDhpw4BygcM59rclO6cb/36o=; b=Ftz8GSH8X+7BGfaIOV9anhXyPrXBl5FkovjJZ2U1kGljUM8eLW2uE1jdMTNJWLu7bK tNtTInxhL6pcr0YyapLnDjHYqCX38JNOhdOEXHdhlp6revK/UDoPfOvu34WWv6b2YAGu OF1IMKy78hB8bxOPPlm/Uu58vXmifSDfQOs+Ae40gibHhcHTC+y3LL2tL6Pju/BKzpLM H6a6ycj+4ktGlcXlmUsXkkOxDSLOymiC5OMvx2LQtyDdJGLNQaf6rJzz17nEVoy5YOTP 81QWgSJwQVJFUGkBqJIjApnQhUaHbhB9kAlVkb2O+74YEtHx4Rw2thgkAIJahctKm1Zt Ne8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HGdkZv/QYmPpRWqwdaGtDhpw4BygcM59rclO6cb/36o=; b=fQJD2TzlF1c7W+ngGfGpG9RPiVkD4gOOMxwJpmEYKUdCCrRptFdUwFdIuMRJ97jYVQ WGNOcRMYZvKkMtWa4fu6+OA6LZmTjxCGTWei+iE/qTPNQFqme2cFxNKDibAvvA3sT081 d++sBc/NJmynst7En1RDUMDpXcbo5y+Tf988STdm9pOisC8Z+X2HLX8cn0afPsH4fl0W HJ16GJtBJQdaIWnLs54zp+Bj/ZYQSbauadwH8uS8jHkg2u9YmPM/voZQPwhak9OWprp+ 1rp7LQ1Psy+t/qG6gzu2Y5s9fL91pK+Gs6Q1WN3RkAUGLM36YEn+wBLebC3X2ASAL/2l loqA== X-Gm-Message-State: ACrzQf2lasgpRo7tyPu/ouP015eG0ocs4emRwupC3L5pUX/paGjcDp9q l3wOLVVYK5IqhgRTJgudA1+PEw== X-Google-Smtp-Source: AMsMyM6S8RkuQkLPETh8CvA3IZDmWK7kQ4LMjXwxlMiEo7SAWsOUMPITADFhxUQcmV4CvIHgZrIX8Q== X-Received: by 2002:adf:f94b:0:b0:236:c825:e2d with SMTP id q11-20020adff94b000000b00236c8250e2dmr4047015wrr.307.1667223120964; Mon, 31 Oct 2022 06:32:00 -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 d17-20020a05600c4c1100b003cf37c5ddc0sm7061449wmp.22.2022.10.31.06.31.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2022 06:32:00 -0700 (PDT) Date: Mon, 31 Oct 2022 13:31:58 +0000 (GMT) From: "Maciej W. Rozycki" To: Simon Marchi cc: gdb-patches@sourceware.org, Andrew Burgess , Tom Tromey , Simon Sobisch Subject: Re: [PATCH v6 5/8] GDB/Python: Use None for `var_zuinteger_unlimited' value set to `unlimited' In-Reply-To: <9777b2ab-49db-e203-377f-5f64022421e7@polymtl.ca> Message-ID: References: <0cf90df8-6943-212a-b4c5-bd5301b44369@polymtl.ca> <9777b2ab-49db-e203-377f-5f64022421e7@polymtl.ca> 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 autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 31 Oct 2022, Simon Marchi wrote: > >> And I do agree that fixing the API once will reduce the long-term costs > >> for everybody (us and users bumping in the inconsistency and losing > >> time). So, I am fine with fixing PARAM_ZUINTEGER_UNLIMITED in this > >> case. > > > > Good. Given that you are in favour to making this change and Andrew was > > against, do you think we need another opinion? Have we reached consensus? > > I didn't know Andrew was against, can you point me to that discussion? This is why I went into such a lengthy justification for the change. I didn't want to just sneak the change in given Andrew's previous concern: . > If the thing is usable as-is, despite being awkward, the alternative is > to just document as clearly as possible the awkwardness. One problem with that is the generalisation I implement in 6/8 (2/4 in v7) makes it even more awkward: we do retain PARAM_ZUINTEGER_UNLIMITED in the Python interface for compatibility reasons, but it will have to be special-cased and extra handling will have to be added (possibly a boolean flag driving the handling of the "unlimited" value and translating it to -1 regardless of the underlying implementation value) to make it different from PARAM_PINTEGER (if we ever expose it to the user) with an "unlimited" keyword explicitly added. Obviously an explicitly added keyword will always translate to `None'. I didn't want to raise the implementation issue at the beginning as I think it's the implementation that should follow the interface and not the other way round, but perhaps it's worth noting in this case after all. Maciej