Presumably because the size of intmax_t was set to something specific on its introduction and changing it now would constitute an ABI break most everywhere.
typedef int intpremium_mediocre_t;First, please stop breaking the site guidelines. You've repeatedly posted unsubstantive/flamebait comments—which as you know, that is not what HN is for. In particular, we ban accounts that do abusive things like https://news.ycombinator.com/item?id=33617059.
Second, please stop routinely creating accounts. As the guidelines say, Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.
intmax_199409L_t for C89's 1994 amendment, etc.
Ironically, this is actually one of the only[0] legitimate uses for standard[1] PRI* macros, since that could expand to whichever of "%llu", "%w128u", etc, was appropriate to the caller.
0: And I'm not sure "one of" is actually needed.
1: as opposed to nonstandard ones like PRIu_xlib_atom or the like
2: Depending on how you define "single", it competes with (x*(uintmax_t)y)>>UINTPTR_BIT, but that's not actually reliable since uintmax_t isn't (IIRC) guaranteed to be larger than uintptr_t.
And now code written to conform with the intent and wording of C99 will need to change?
If you have an interface that has a function that e.g. takes an intmax_t parameter (and even the C standard has those, e.g. imaxabs()), increasing intmax_t size (ABI change) would break existing callers.
So you can only change intmax_t size if you do not care about ABI stability.