From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id B8BB63858289 for ; Wed, 8 Mar 2023 15:48:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B8BB63858289 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-io1-xd32.google.com with SMTP id bf15so6928145iob.7 for ; Wed, 08 Mar 2023 07:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1678290490; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=1fO9hSklvE10Xu7Yeo1e6KcFWy+mrnAIflNRuZfsFRY=; b=X6fHnO9j9P68ka1u5bUsrH4rkrjuXvq0fAiXzmfHorPqyW6SEhIcJPrHlkR3+rROvY KAm9imn/5ziqJLa4YTrP//OGNbQnQ0ty/sJAzVu/M92WrSJh9G40nGUFW55YQ+1QkDaL 3mii6Icjw6h+zdtHV8eRHVbdx63V65miUaNpQxX4nA/SkjLOTjkSWA6GX8YHfLgUE+5q X7JXM9qzje+xsjL/yM5/DAS7ZlPkEc/36Fmzy9nauqyM8NdcV29TeLnvJax0kh3VopFf ekpe4CrVguZ0GjpuETOf+reH1Dd0JMdy0ZWV3Gml4VKzhinqY2MlghMFTU3G0KYB9GBK NLvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678290490; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1fO9hSklvE10Xu7Yeo1e6KcFWy+mrnAIflNRuZfsFRY=; b=zMdPh+pZ+kOlDDF8pp7EPdtjkNZbX8HcPJ2b+QxSiazrg7wIrFKM9eu2rNCFjVsDxD b7haiz/iqXXZoTdmnx05b0Ub/hHknWyt86UnwgDS6dBCSRD5wFVKG6hyivrmDbG2LCGl e5cbn/jDAEafQa3iXjqUwD1RtQY690iyz6uCHWhgd1a185sFnfpbhESgZ9q/9tNYh8B0 qXlLQyJXHCBHR1MF95FAHR6sGYb/JFAyoVnvPR3KUeseq1XuroVrl8I63EYc8bZqWi0o G50i+tUrkUzGYmgAR/M5X+Jfrap8YK+3XnnLpV0mlm2iTdT+ZLLmwt6DNlHNQ+z+rtix yI2Q== X-Gm-Message-State: AO0yUKWU4dziN8CWPRkl/j/tkOu96+4INeXdiUjtizpYpwoEOuHNtEBX CCqqdAf8X2nbYiC+0Z3oGPTlbA== X-Google-Smtp-Source: AK7set9/Z4WclYmEJHpWYul2xxLxloydSb+utF+6Fo8rqdQaWllVuaGgnKg+gjpwXqJG0y27ged+vA== X-Received: by 2002:a5d:8415:0:b0:71e:d132:d08f with SMTP id i21-20020a5d8415000000b0071ed132d08fmr13565655ion.9.1678290489827; Wed, 08 Mar 2023 07:48:09 -0800 (PST) Received: from murgatroyd (75-166-130-93.hlrn.qwest.net. [75.166.130.93]) by smtp.gmail.com with ESMTPSA id v4-20020a5ec104000000b0073fe9d412fasm5110478iol.33.2023.03.08.07.48.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Mar 2023 07:48:09 -0800 (PST) From: Tom Tromey To: Lancelot SIX Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 4/8] Add value_as_mpz and value_from_mpz References: <20230303211207.1053037-1-tromey@adacore.com> <20230303211207.1053037-5-tromey@adacore.com> <20230308104706.xm4mhantoflbud63@ubuntu.lan> X-Attribution: Tom Date: Wed, 08 Mar 2023 08:48:08 -0700 In-Reply-To: <20230308104706.xm4mhantoflbud63@ubuntu.lan> (Lancelot SIX's message of "Wed, 8 Mar 2023 10:47:06 +0000") Message-ID: <87sfefnt1j.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.5 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: >> + unsigned n_bytes =3D ((bit_off % 8) + bit_size + 7) / 8; Lancelot> This is a bit out of the scope of this patch as gdbvalue.h says t= hat Lancelot> bit_off / bit_size are 8 based, but should they be HOST_CHAR_BIT = based Lancelot> instead? The n_bytes is used to to access a Lancelot> "gdb::array_view". Yeah, I do not know. I am not sure I've ever understood how gdb intends to handle these scenarios, if it even really does. I do see uses of HOST_CHAR_BIT, but also plain '8'. Also there's this weirdness: #if defined (CHAR_BIT) #define HOST_CHAR_BIT CHAR_BIT #else #define HOST_CHAR_BIT TARGET_CHAR_BIT #endif It's hard to understand how this can ever make sense, even despite the comment (which may be obsolete). TARGET_CHAR_BIT is even worse because surely it cannot be a constant. Anyway, this code in question in this patch is just copied from elsewhere. >> + storage.mask ((ULONGEST) 1 << bit_size); Lancelot> I=E2=80=AFdo not think you should have the "(ULONGEST) 1 <<" part= here. Lancelot> gdb_mpz::mask does mask N bits (N being its arg). Thank you. Tom