Hacker News Reader

So, a "what your mother didn't tell you about C standardization!". I.e. that some popular compilers flaunted the standard, as wider and supported integers should surely have been "[u]intmax_t".

And now code written to conform with the intent and wording of C99 will need to change?

View on HN

No, the ABI issue is fundamentally there regardless of what compilers did or didn't do.

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.

Exactly, and the way "intmax_t" was previously defined in C99 implied that you needed to break that ABI compatibility if you introduced larger integer types.

Are you saying that the standard should attempt to impose requirements to non-conforming compiler modes? How would that even work?

I'm saying that if you wrote conforming C99 code that made the assumptions C99 guaranteed your code will be subtly broken by C23. Whether that was a worthwhile trade-off is another matter.

To be fair C23 is simply standardising the status quo. There is no point in having a standard if nobody implements it.

Reply on news.ycombinator.com