Re:A Special Kind of Hell: intmax_t in C and C++
by simias on Saturday December 05, 2020 @05:59PM
(#25319258)
Yeah I think I agree with you and stncls, the practical conclusion is that one probably shouldn't use intmax_t in external ABIs.
Not that it should be much of a concern in practice, as far as I can tell intmax_t seems mostly about writing "generic" integer code without having to specialize for any int type, but that wouldn't make for a very clean or idiomatic public C API IMO. At least I don't think I've ever encountered it in the wild.
Re:A Special Kind of Hell: intmax_t in C and C++
by loeg on Saturday December 05, 2020 @07:11PM
(#25319683)
> Not that it should be much of a concern in practice, as far as I can tell intmax_t seems mostly about writing "generic" integer code without having to specialize for any int type, but that wouldn't make for a very clean or idiomatic public C API IMO. At least I don't think I've ever encountered it in the wild.
I think you're exactly right. That's what I was trying to suggest and address with: "Integer size-generic routines are best served with wrapper macros and use of the C11 _Generic() construction, or some of the typeof() magic used by, e.g., Linux." It predates the C11 _Generic() stuff, and the standards ignore the GCC extensions like typeof().
intmax_t is supposed to store any sized integer type. If you introduce a int128_t, it doesn't have any impact on 'int.' But it does mean that your intmax_t must be int128_t, and if it was 64-bit before, now your ABI changes (for intmax_t-using ABIs). Ordinarily introducing a new type or function wouldn't cause ABI incompatibility, but introducing a wider integer type that intmax_t cannot represent is not a valid choice.
I'd suggest considering ABIs with intmax_t in them unstable, and probably just avoiding use of intmax_t in ABIs entirely. Integer size-generic routines are best served with wrapper macros and use of the C11 _Generic() construction, or some of the typeof() magic used by, e.g., Linux.