Hacker News Reader

Comment by avar | Hacker News Reader

"Extended integer types may be wider than intmax_t". I'm sure there's a good reason for this, but it was introduced in C99, which says (in 7.8.1.5): "[intmax_t] designates a signed integer type capable of representing any value of any signed integer type".

That was already portable between 16 bit, 32 bit, 64 bit etc. Why is it that just because the compiler supports 128 bit or 256 bit integers that compiling in such a mode doesn't correspondingly update "[u]intmax_t"?

The linked page says they 'cannot be "extended integer types" in the sense of C17', but that printf() and scanf() should still support these?

View on HN

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.

That’s exactly right. On platforms without ABI stability concerns, there’s no issue, but if you can’t change the ABI intmax_t is stuck being what it’s always been (which is why it was always obviously a bad idea and should not have been included in the standard).

No problem, just introduce intreallymax_t and later intmaxthistimewereallymeanit_t.

int -> intpro_t -> intmax_t -> intultra_t

I think you missed the intpromax_t type, which is a bit more better.

And then there is intpremium_t which is required to be somewhere between intpro_t and intultra_t but has no relation to intmax_t, just for some additional fun.

intpremium_t is only available to paying ANSI-members.

    typedef int intpremium_mediocre_t;

I need to ask you a couple things. (This is not particularly a response to the current comment - I just need a recent place to post this.)

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.

https://news.ycombinator.com/newsguidelines.html

Or include the std version in the name.

intmax_199409L_t for C89's 1994 amendment, etc.

They could introduce a similar type that is prohibited (checked by the compiler) from occurring in declarations with external linkage (plus some wording regarding casting of data across translation units being undefined behavior for that type). Effectively prohibit it from being used in ABIs. It would then still be useful for intermediate calculations and in macros.

They could have retroactively made intmax_t that type. Anyone using intmax_t in ABIs can keep using C11 until they fix their ABIs.

C uses intmax_t in its ABI. I’m all for deprecating those ABI, because they’re crap, but the C committee doesn’t see it that way.

That doesn't work because possibly[2] the most important single use of uintmax_t is the printf specifier "%ju", ie a ABI boundary.

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.

I meant a new, separate type, in addition to the defunct existing (u)intmax_t. For that new type, %j(u) wouldn't apply, but of course a PRI* macro could be added for it as you suggest.

I'd argue that printf and va_args are terrible and should have been depreciated 25 years ago.

Also a 128 bit intmax_t would be slower and the 128 bit extensions are used only rarely.

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?

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.

Technically, it would break ABIs. I agree, they should have just broken any ABI relying on intmax_t and made it definitionally unstable (instead of making it useless, which they've chosen to do instead).

Reply on news.ycombinator.com