Re: [PATCH v3 2/4] util: Introduce read_file() and read_file_long() function

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Wed, Oct 29, 2025 at 05:43:16AM +0100, Stefano Brivio wrote:
> On Wed, 29 Oct 2025 11:43:00 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > 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 the
> > > Linux kernel (hence, most architectures we support):
> > > 
> > >   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.
> > > 
> > > 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.
> 
> 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)?
> 
> > 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.
> 
> 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.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]