Interesting read but IMHO fairly irrelevant for language users. I've been coding in C and C++ for more than 25 years and never encountered intmax_t or any problems related to it.
It's better to accept that C (and C++) are only portable in theory, in reality it's nearly impossible to write non-trivial code which compiles without warnings in a different compiler or runs out of the box on a different hardware architecture (still the language does a pretty good job at it everything considered). IMHO the standard committees should focus on the (handful) platforms that exist today, and not care too much about legacy or future platforms. The C standard shouldn't be some "pure ideal", just harmonize the differences between compilers and platforms, and only so far as it makes sense for real-world code.
Personally I'd rather see extensions from gcc and clang moved into the standard which are already battle proven instead of wasting time fixing 30 year old problems.
It's better to accept that C (and C++) are only portable in theory, in reality it's nearly impossible to write non-trivial code which compiles without warnings in a different compiler or runs out of the box on a different hardware architecture (still the language does a pretty good job at it everything considered). IMHO the standard committees should focus on the (handful) platforms that exist today, and not care too much about legacy or future platforms. The C standard shouldn't be some "pure ideal", just harmonize the differences between compilers and platforms, and only so far as it makes sense for real-world code.
Personally I'd rather see extensions from gcc and clang moved into the standard which are already battle proven instead of wasting time fixing 30 year old problems.