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=mVQiHMmg; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id B72545A061A for ; Wed, 29 Oct 2025 10:37:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1761730657; bh=9eLJe+quyh1qbtTM3XTGyG1mV9coxg/iexdl/r7sE20=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mVQiHMmgax2qOYTb4ypSwq4xUlTGuDVoTd0Vc/VIsm0H/B8CGUIPQTFmxXV//d51I iEExlqPmn1YBGxrWNp3ofQFBbgfRizJzWL75YDB4RTKF4LcWM6+y7BQH7/WJoTsFSa Iez8DmnXJ4ft4g+H/S6vQBdbDkAqdd08CyiyScza3BOFoFW2okSB4JYZJVcjvuMmf4 1sAd/MZliJ0WOkyNCyx6ffhGvQFWrg+fhHQKeRPo/4ZZMR2U/NHZCWagPeQz1nAkK6 y0TeOlIyjvL1ZpdGamY7fVArF9lXnZn8Qa2wjw7qkfjHB3Wf4zyjCedntcQZbW83n2 GFHUCFaGEiVtw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4cxMbj6Qx3z4wM9; Wed, 29 Oct 2025 20:37:37 +1100 (AEDT) Date: Wed, 29 Oct 2025 20:35:08 +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> <20251029054316.05fe73aa@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="c8WptkPrVnqTwl9U" Content-Disposition: inline In-Reply-To: <20251029054316.05fe73aa@elisabeth> Message-ID-Hash: PN36XBIINSLBCDQHAFYPBJP7NJIXCO5D X-Message-ID-Hash: PN36XBIINSLBCDQHAFYPBJP7NJIXCO5D 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: --c8WptkPrVnqTwl9U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2025 at 05:43:16AM +0100, Stefano Brivio wrote: > On Wed, 29 Oct 2025 11:43:00 +1100 > David Gibson wrote: >=20 > > On Wed, Oct 29, 2025 at 12:12:48AM +0100, Stefano Brivio wrote: [snip] > > > 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 t= he > > > Linux kernel (hence, most architectures we support): > > >=20 > > > https://wiki.debian.org/ArchitectureSpecificsMemo#Summary =20 > >=20 > > Oh, nice, that is a very handy resource. > >=20 > > > and judging from intmax_t(3type) I'd say that the sizeof(long double) > > > column tells you how big intmax_t is. =20 > >=20 > > > Well, at least, that's the page I use to know which architectures I c= an > > > use to check things when I suspect a type portability bug. > > >=20 > > > That's because 'long double' should always be the biggest "native" da= ta > > > type, that is, excluding __int128 or vectorised / SIMD types such as > > > __m256i. =20 > >=20 > > 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. >=20 > Oops, yes, I misread intmax_t(3type), that's *integer* only (of course, > the name says it). So probably it has to match sizeof(long long)? >=20 > > 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. > >=20 > > I think sizeof(long long) is more likely to match sizeof(intmax_t), > > but I don't love relying on it. >=20 > Right... well, about relying on it, without a change in the C11 > standard, can it ever differ? I don't think so. We could have a look at > C17 / C23 and if long long is still the largest integer type, we know > we're fine for quite a few years / pretty much forever. Uh.. maybe? I'm never clear on what's guaranteed by the C standard and what's left to the platform / ABI. AIUI the reason for intmax_t's existence is because an awful lot is not pinned down by the standard. __int128 does appear to be a thing that is longer than long long. Maybe there's a rule that doesn't allow intmax_t to be __int128, but I'm not sure where we'd find 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 --c8WptkPrVnqTwl9U Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmkB38cACgkQzQJF27ox 2Gfxvw/8Cb1QEBUjMnicR8fAeQgaO9qF8NhHfijx7iJlVM0b7iMZYVIhaPitsYiK 8UrFajJZutkSwssj5lKTFRIrdwCtXePz+ESCtjgsTzlBS53R1RGiMq35gB/DjJem 4+Tlmo87G/0PepCxRQP9T3qJb4QrPlipPmmMt/nsc/UxK/1Vj5VJyJkhNSMFfHcu tbLr8YGBZaHXMUt/K6ZkvY3eN/o8HDZzLeGpgdLB2A8GKUrM1jDRZe+ipJI7NM9I 8NeWje0wz7eYkSK6e6QNguBxT5hS5dKunguNUCaMQ3tXIk7ymwj35+9hiAe3mdV4 z7lTfh3lWkBOIoXyFyUi8pSHYoCecTWkkWc5rcIF0FTiEooICRwdbWuS1/76k1cb 7Nr07qKLdF9EJcbAcTk5/Jp6VlCZRw5z2QK8nJL12dGY5iiMHLpQkoYN2yfORfW0 UjAwquCNNIq/HWlaM3H2ZIRGZm2Is29/qculMlzAdGhyzjHr/F0zxIXe6kI/qewV yjx2SXPCUS1o4H3V6MRZkHjcdIHKuhVxbwHaPGJ8lKri5fu8P5oU3Af0qYgWSEFB /aYgW+f9tva94Uwugode63yYxn+/VIp/OKIWnz0LA/SP3P65K6K+vpqDgV2V0mAz 8AyQa+Wx13WO7ZFC2ulN8akMR4PxJzL40CFxlKtgPU+Ru9Er7yk= =+H26 -----END PGP SIGNATURE----- --c8WptkPrVnqTwl9U--