intmax_t should be kept out of stable ABI definitions, and out of API's.
There has to be an ABI for it because we have to pin down what it means to pass an intmax_t as an argument to a function, how it is aligned on the stack if passed that way, and how it's placed into a structure and so on.
However, there could be a provision that the ABI treatment of intmax_t is not guaranteed; it is subject to change due to the redefinition of intmax_t.
And, for that reason, it should be kept out of API's.
That leaves API's that deal specifically with intmax_t itself rather than using it to represent something. Those can use aliasing and versioning.
today intmax_t might be 64 bits, so the application should be compiled in such a way that the call to intmax_div goes to some __intmax_div_64, which looks like this:
Even when intmax_t changes to 128, that compiled program continues to reference __intmax_div_64 which uses int64_t parameters and structure members. A newly compiled program calls __intmax_div_128.
A particular problem would be functions in the printf family. Say we have a conversion specifier which prints intmax_t which is 64 bits today. Here, the solution is even simpler. The "PRI" macros introduced in C99 provide it. Given an intmax_t value x, we print it like this:
printf("x = %" PRIdMAX "\n", x);
so today that might expand to some conversion specifier that is identical to the one for PRIx64. And so that compiled program will have that baked into its conversion string, so everything will continue to be the same even if the platform moves to a 128 bit intmax_t.
A newly compiled program on the 128 bit intmax_t platform will get a different PRIdMAX
string from the header file, which expands to a conversion specifier matching int128_t.
Basically all the issues are solvable except the issue of some application code carelessly using intmax_t in its APIs without any plan for versioning.
Comments
intmax_t should be kept out of stable ABI definitions, and out of API's.
There has to be an ABI for it because we have to pin down what it means to pass an intmax_t as an argument to a function, how it is aligned on the stack if passed that way, and how it's placed into a structure and so on.
However, there could be a provision that the ABI treatment of intmax_t is not guaranteed; it is subject to change due to the redefinition of intmax_t.
And, for that reason, it should be kept out of API's.
That leaves API's that deal specifically with intmax_t itself rather than using it to represent something. Those can use aliasing and versioning.
Say we had a function like this:
today intmax_t might be 64 bits, so the application should be compiled in such a way that the call to intmax_div goes to some __intmax_div_64, which looks like this: Even when intmax_t changes to 128, that compiled program continues to reference __intmax_div_64 which uses int64_t parameters and structure members. A newly compiled program calls __intmax_div_128.A particular problem would be functions in the printf family. Say we have a conversion specifier which prints intmax_t which is 64 bits today. Here, the solution is even simpler. The "PRI" macros introduced in C99 provide it. Given an intmax_t value x, we print it like this:
so today that might expand to some conversion specifier that is identical to the one for PRIx64. And so that compiled program will have that baked into its conversion string, so everything will continue to be the same even if the platform moves to a 128 bit intmax_t.A newly compiled program on the 128 bit intmax_t platform will get a different PRIdMAX string from the header file, which expands to a conversion specifier matching int128_t.
Basically all the issues are solvable except the issue of some application code carelessly using intmax_t in its APIs without any plan for versioning.