From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202510 header.b=ZnFxOCyr; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 075545A0619 for ; Wed, 29 Oct 2025 01:43:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1761698586; bh=qR3oJyaDexxHTn/ofOmaeNXSsfnfcS8TzKV4M/2Ei+w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZnFxOCyrFxB2UwPZeEPUMDR+GxFjSRbG1r0WyAu3pc20Np8OWfKC8Xkw3+P0wVsSu Ow7d2ockXQcm5VkWuvrOxxV+He7uw1Ccamks2MEpeulruAH053wXSOe0hE0/HNXAE9 q6nxo9lCdg1zgdZF4caPL65TkQLi3gWir7Sa1j8xUWlpWOomD8ulAJS5zcOKQUIGwK bd6K9BS/7piCKm9bYcbT0XLXwl4sMNdMU+zhmIjka34K/6H+SxWqVR4VGCnkVTQKJ8 PlxJGuSOWRt/KmGXMV4x+0J30x0nLmsk/HekKUni3+lt/X+hV3dntOrezSBojmOVlc gs2i27SViZzwA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4cx7ky6bdGz4wM4; Wed, 29 Oct 2025 11:43:06 +1100 (AEDT) Date: Wed, 29 Oct 2025 11:43:00 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v3 2/4] util: Introduce read_file() and read_file_long() function Message-ID: References: <20251014073836.18150-1-yuhuang@redhat.com> <20251014073836.18150-3-yuhuang@redhat.com> <20251029001248.09193eb4@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QpQuUpcwCGyMYUjs" Content-Disposition: inline In-Reply-To: <20251029001248.09193eb4@elisabeth> Message-ID-Hash: RDB3KKBJCFLSVY2RZWUJXEFWNSTSKXMS X-Message-ID-Hash: RDB3KKBJCFLSVY2RZWUJXEFWNSTSKXMS X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Yumei Huang , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --QpQuUpcwCGyMYUjs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2025 at 12:12:48AM +0100, Stefano Brivio wrote: > On Wed, 15 Oct 2025 15:46:12 +1100 > David Gibson wrote: >=20 > > On Wed, Oct 15, 2025 at 11:50:53AM +0800, Yumei Huang wrote: > > > On Wed, Oct 15, 2025 at 7:28=E2=80=AFAM David Gibson > > > wrote: =20 > > > > On Tue, Oct 14, 2025 at 03:38:34PM +0800, Yumei Huang wrote: =20 > > > > > Signed-off-by: Yumei Huang =20 > > [snip] > > > > > + * @path: Path to the sysctl file > > > > > + * @fallback: Default value if file can't be read > > > > > + * > > > > > + * Return: Parameter value, fallback on failure > > > > > +*/ > > > > > +long read_file_long(const char *path, long fallback) > > > > > +{ > > > > > + char buf[32]; =20 > > > > > > > > Rather than just using a semi-arbitrary 32 here, I'd suggest defini= ng > > > > a new constant similar to UINT16_STRLEN. Except that's trickier fo= r a > > > > type that doesn't have a known fixed width. Pity the C library > > > > doesn't have constants for these AFAICT. =20 > > >=20 > > > I will just define a UINTMAX_STRLEN with (sizeof("2147483647")). =20 > >=20 > > That's not quite right. > > - It should be INTMAX_STRLEN (signed), UINTMAX would be for the > > unsigned version > > - That assumes intmax_t is 32-bit which is probably not the case (it > > will be 64-bit, maybe even 128-bit on modern systems) > > - For signed cases, it's the minimum (negative) value that gives the > > longest possible string (for 32-bit, "-2147483648") >=20 > By the way, while it doesn't cover intmax_t explicitly, I think this is > a pretty good resource as it covers most architectures supported by the > Linux kernel (hence, most architectures we support): >=20 > https://wiki.debian.org/ArchitectureSpecificsMemo#Summary Oh, nice, that is a very handy resource. > and judging from intmax_t(3type) I'd say that the sizeof(long double) > column tells you how big intmax_t is. > Well, at least, that's the page I use to know which architectures I can > use to check things when I suspect a type portability bug. >=20 > That's because 'long double' should always be the biggest "native" data > type, that is, excluding __int128 or vectorised / SIMD types such as > __m256i. This part isn't true, alas. Theoretically speaking there's not necessarily any relation between the largest native integer type and the largest native float type. But more importantly, it's not true in practice: according to the table sizeof(long double) is 16 for amd64, but sizeof(intmax_t) is 8 empirically. I think sizeof(long long) is more likely to match sizeof(intmax_t), but I don't love relying on it. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --QpQuUpcwCGyMYUjs Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmkBYxMACgkQzQJF27ox 2GdyEw//bhVYGZTnFD6G1MsHK8aHKjLv4vPuhr2YOPlfWTRW5XvIaph4SvJOQwFR rNXpja/mDITLV3kVjFnxHSy4icAKuJkJIY3156d0rN8m4xBBYtJDGLv957PcYAev wQ/MDpKs8Qtac9x0VGEQbNDAIsvWXN0/0g6Ko0TGNk7WdNqGZewJKeUez9rR3kWO eeQxn4BeBea8KHOEZFWmZEC2PB6Kjw4wNub3quLWLOYaGVh9PxYa8bm18js2MRb5 UqofG7aByGL+MetwSy2sBeFj4biXS+Wjj94mklQTf2sPNjCmuiIwToA0zmSq9wK4 RbCRBjRVh3DfnBHFEEoDxkb8FOnIyCGQsS4z/S5KzUKH6MvAEmCV2AygB9UwmZnA 5Bq6gP9ygZMDJrWhx7YAVlUKeaBb8yyGfoZw6o7ZFtjZUftnI1FHzZjtkiQWCYnR jdyuMndaoJsOjwX8VOP7o2dY+bVy5XOOY87ZQZnSFq2+gI0z/T23NCLeDga4+5lK Bwf10L+GmCchwMm1UPA1nhUt5R6xAhPfViWEZKzS84TfPSHmUkCZZ67HSLfw1FsB xVmInj469AfeiY39kpdhtrtF2oTWoILWBjXoxDnIWyvhf+4Dpbu//78jM6grBhW2 ssKXyOcgGbfYIATzphVL0Q9BEQAIrzNk7zIL9avmZMYNB00ir1I= =KSMg -----END PGP SIGNATURE----- --QpQuUpcwCGyMYUjs--