If people use intmax_t and then they expect the ABI to stay stable, than they are at fault, not libc, LLVM or GCC for changing it when the actual "max int" changes.
If you want to know "what is the widest signed integer type available", you will get some kind of answer one way or another.
Obviously, when someone says “type X is size Y on architecture Z”, they’re not talking about the C standard, they’re talking about some particular ABI.
There are multiple ABIs for x86_64. I think the major compilers use 32 bits for int and 64 for long, but there could very well be a compiler that used different sizes, with a different ABI.
> A compiler vendor can set the sizes to whatever they want regardless of the target architecture and claim conformance if they meet the minimum.
Compilers claim conformance with other standards besides just the C standard.
Well, that code is not, and was not ever, standards compliant.
After all, if predictable behavior in the future across all possible configurations were a high priority requirement for the tools people use to make computers do things, neither C nor C++ would have gotten off the ground. Instead, people don't memorize the entire standard. They write code that works on their machine, publish it, fix the bugs when people say it doesn't work on their machine, and maybe converge towards something that is standards compliant but, more likely, they converge towards something that works on the standard implementation on 90% of the operating systems available.
Would you be able to name three examples?
My intention was to make a good case for old code being compiled today by third parties.
But to my understanding intmax_t was introduced in C99, before widespread dominance of 64 bits platforms. So it would not be surprising that there exists code with lower assumptions about its size.
But actually I made also another mistake, the major problem had little to do with faulty logic and more to do with dynamic linking [0]
I will see myself out today.