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

On Wed, 29 Oct 2025 20:35:08 +1100 David Gibson wrote:

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:

...

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.

The standard specifies long long, without a width, and not long long long, so we know that long long is the longest we can have at the moment.

__int128 does appear to be a thing that is longer than long long.

Yes but that's what I meant by "native" type, for lack of a better name. It looks like they're more commonly called "main" types instead. __int128 is a GNU extension and specifies a 128-bit width just like __m256i specifies a 256-bit width. Those can be bigger than intmax_t.

Maybe there's a rule that doesn't allow intmax_t to be __int128, but I'm not sure where we'd find it.

No real rule but BUGS in intmax_t(3type) reports this (even though it doesn't look like a bug to me). -- Stefano