If you want to know "what is the widest signed integer type available", you will get some kind of answer one way or another.

But of course, ABI’s are important, since proprietary binary blobs are what is important.

    uint64_t foo = ...;
    printf("foo = %ju\n", (uintmax_t)foo);
    /* OR */
    printf("foo = %llu\n", (unsigned long long)foo);

The compiler support for that is limited, though. To let N be >128 in Clang, -fexperimental-max-bitint-width=N flag can be provided. If N>128 and _BitInt(N) is divided by something, the compiler will just crash, but +, -, * all work as expected.

Signed overflow is undefined behaviour so the compiler and runtime can do anything. But, where would it store the extra bits? It could call malloc, but it wouldn't know when to free. It would violate the expectation that memory is managed manually in C. Not all C code even uses malloc. Or, what if the int is in a struct? Should the implementation go allocate extra overflow space elsewhere, and then what happens when you memcpy the struct?

I think there is a strong impedance mismatch between bignums and languages that aren't garbage collected.

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?

Edit: I guess that wasn't the point of your example (that it may not be easily recognisable as a bug?)

C99 defines int8_t, if it exists, to be a 2's complement signed integer of exactly 8 bits. Same for 16, 32, etc. The standard could very well define behavior on overflow for these (that is, turn them into actual types instead of typedefs), and leave int, long, etc alone. I think this would be a viable, realistic, solution. Integer conversions would probably still be a pain, though.

If you have an ABI, you need to put an explicit size and signedness on every parameter and return value. Period. No excuses.

No "int". No "unsigned int". If I'm being really pedantic, don't even use "char".

It should be "int32_t", "uint32_t", and "uint8_t".

Every time I see objections, it's always someone who wants to use some weird 16-bit architecture. The problem is that those libraries probably won't work anyhow since nobody tests their libraries on anything other than x86 and maybe Arm. If your "int" is 16 bits, you're likely to have a broken library anyway.

Wrong both for worst-case C and for "16 bits in size": the actual maximum is "32 thousand-something" (specifically 32767 in 2s-complement and also in most of the stupid representations (like 1s-complement or sign-magnitude), although there might be some that have, eg, 32768). They also have a minimum of -32768 (or -32767 or otherwise for some of the stupid representations).

You could intepret it as "65 thousand-something" values between the minimum and maximum, but that strongly implies that the minimum doesn't need to be specified, which only works for unsigned integers (which C int is very much not).

In other words, C allows that UINT_MAX == INT_MAX, in which case you will overflow.

If they made that assumption, they should explicitly mention it, but they didn't.

> Update 17 Feb 2008:... ...Now that we've made this change, we know that the program is correct;)

It seems the article is aware of the irony. Another update would be in order.

Smart programming languages have bignum integers and seamless promotion between fixnum and bignum versions. Thus they avoid the issue completely, no stupid casts (especially casts which change both signedness and size), no overflows, no nothing, just an integer length.

It's a perfect world and everyone should try to achieve it.

C is not such programming language, with the closest approximation being uintmax_t.

size_t is of course enough in practice.

bitwise x = 0x1234; x |= 0x1000;

(0x indicates a bitwise value.)