C Integer Type Sizes

In C, you only have char, short, int, long and long long (signed and unsigned). Other integer types like uint32_t and size_t are typedefs to those. If int is 64 bits and char is 8 bits, you have to choose if short is 16 or 32 bits, and other one won't exist at all.long really should be 64 bits of 64-bit systems, and it is on Linux. Windows kept it at 32 bits to make porting existing code easier.

Isn't "int" 64-bit on some (rare) architectures?

Int is not large enough for 64 bit system. ptrdiff Is always the correct size and is signed unlike size_t

Is there a reason it wouldn't be 16 bits like in C?

Long shouldn't be avoided. The rule has always been 32-bits minimum. If that covers the range you need them you're good on every standards compliant platform, otherwise you use a different type. That is how the C native integer types are supposed to be used to maintain forward portability across different word size architectures. What is wrong is to blindly assume your types are larger than the minimum or exactly equal to the minimum.

Likely targeting c89, which doesn't have the fixed-size ints (nor size_t, as the sibling suggests).

There are 64 bit systems where "long int" still is only 32 bits. (most importantly: Windows x64)In general, the C integer types cannot be relied upon; typedefs like uint32_t, size_t, ptrdiff_t should always be preferred.

It may be crazy but it's not exactly without precedent. Neither C nor C++ fix the sizes of the fundamental integer types, although for backward-compatibility reasons popular 64-bit platforms still have 32-bit `int` and even `long`. But yeah, there's a reason eg. Rust has no `int` and friends but `i32` etc. instead.

Isn't this what C99's uintptr_t type tries to address?

Anybody who cares about integer sizes in any more detail needs to use things like int32_t.