5 ms·
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.
by tpush 4y ago
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.
- stephencanon 4y agoThat’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).
- codeflo 4y agoNo problem, just introduce intreallymax_t and later intmaxthistimewereallymeanit_t.
- formerly_proven 4y agoint -> intpro_t -> intmax_t -> intultra_t
- jraph 4y agoI think you missed the intpromax_t type, which is a bit more better.
- Joker_vD 4y agoAnd 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.
- amag 4y agointpremium_t is only available to paying ANSI-members.
- pwdisswordfish9 4y agotypedef int intpremium_mediocre_t;
- dang 4y agoI 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 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 https://news.ycombinator.com/newsguidelines.html
- SAI_Peregrinus 4y agoOr include the std version in the name. intmax_199409L_t for C89's 1994 amendment, etc.
- layer8 4y agoThey 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.
- loeg 4y agoThey could have retroactively made intmax_t that type. Anyone using intmax_t in ABIs can keep using C11 until they fix their ABIs.
- stephencanon 4y agoC 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.
- a1369209993 4y agoThat 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.
- layer8 4y agoI 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.
- Gibbon1 4y agoI'd argue that printf and va_args are terrible and should have been depreciated 25 years ago.
- rwmj 4y agoAlso a 128 bit intmax_t would be slower and the 128 bit extensions are used only rarely.
- avar 4y agoSo, 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?
- AnssiH 4y agoNo, 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.
- avar 4y agoExactly, 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.
- gpderetta 4y agoAre you saying that the standard should attempt to impose requirements to non-conforming compiler modes? How would that even work?
- avar 4y agoI'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.
- gpderetta 4y agoTo be fair C23 is simply standardising the status quo. There is no point in having a standard if nobody implements it.