3 ms·

>The glibc maintainers decide they’re going to change from long long as their intmax_t and move to __int256_t for most platforms, because most platforms support

by simias 6y ago

>The glibc maintainers decide they’re going to change from long long as their intmax_t and move to __int256_t for most platforms, because most platforms support it and they have a lot of customers asking for it. Is this a practical concern? That seems like such a strong calling convention change that it wouldn't really bother me if you had to recompile all your software in this situation. I mean, let's even imagine that there would be a way to make this change somewhat transparent and automated. You still end up with some types magically now taking 256 bits instead of (probably) 64bits before that. If you use this type a lot the performance implications are pretty huge, both in terms of actually doing maths with a 256 bit integer, but also for RAM and cache usage. If you suddenly changed int to be 64 instead of 32bits you'd have a similar problem for instance. I don't think anybody would expect such a change not to require a full recompile. So what's the difference here?

stncls 6y ago
> Is this a practical concern? > That seems like such a strong calling convention change I think you are spot on here. The OP's concern may be due to things like this: > For example, let’s take a C Standard function that uses intmax_t, imaxabs It looks like an unusual departure from typical libc functions like strtol(), strtoll(), etc. which have a primary type right in the name. To the untrained eye, intmax_t may look like some promise of portability, when it is actually no more portable than specifying int or long.
loeg 6y ago
> If you suddenly changed int to be 64 instead of 32bits you'd have a similar problem for instance. I don't think anybody would expect such a change not to require a full recompile. So what's the difference here? 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.
- simias 6y ago
  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.
  - loeg 6y ago
    > 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().

by simias 6y ago

stncls 6y ago

> Is this a practical concern? > That seems like such a strong calling convention change I think you are spot on here. The OP's concern may be due to things like this: > For example, let’s take a C Standard function that uses intmax_t, imaxabs It looks like an unusual departure from typical libc functions like strtol(), strtoll(), etc. which have a primary type right in the name. To the untrained eye, intmax_t may look like some promise of portability, when it is actually no more portable than specifying int or long.

loeg 6y ago

> If you suddenly changed int to be 64 instead of 32bits you'd have a similar problem for instance. I don't think anybody would expect such a change not to require a full recompile. So what's the difference here? 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.

simias 6y ago
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.
- loeg 6y ago
  > 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().