long can't be smaller than int, so a 64-bit int leaves short as the only type between char and long long, and you need to pick whether it's 16 bits or 32.
replyThen again, we'd still have stdint around. And ultimately this doesn't matter because most code isn't portable anyway.
You would still want a native 16 bit type in order to have a pointer to a 16-bit memory location, including an array of 16-bit values.
replydeleted
replyI don't think of the stdint types as being less native than the keyword integer types. C# for example makes keyword types aliases to System.* types, not the other way around.
replyI think you would need to have a compiler intrinsic type which is 16 bits. That is what the stdint.h file would define (u)int_16 to.
replyIt would be odd for there to be a compiler intrinsic type to be unavailable until a header was included.
The compiler intrinsic type could be a mess like __int16_exactly_t but without it stdint.h would have some magic line which makes a compiler intrinsic available which wasn't before, or generates a new 16-bit type ex nihilo.
So you could have a "#pragma expose_extra_types" in stdint.h but that would not be the conventional approach.
I mostly wanted to make the point that a mere "at least 16 bits" type is not sufficient for some use cases, which is not in response to you but the comment you responded to.
Yeah, in GCC for example, we can define exact width types without including `<stdint.h>`.
reply typedef unsigned __attribute__((mode(HI))) uint16_t;
typedef signed __attribute__((mode(SI))) int32_t;
[dead]
reply