5 ms·
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 be
by stephencanon 4y ago
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).
- 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.