> Shouldn't they be 64 bits on most modern systems then?
Arguably so, but then one would lose the ability to natively name 16-bit integer types because "short" would be 32 bits.
An earlier comment addresses x86-64. AArch64 (pedantically, the A64 instruction set used for AArch64's 64-bit execution mode) is similar, in that addresses are 64 bits wide but ALU instructions typically encode a width bit, called "sf", that selects either 32- or 64-bit data registers and arithmetic. See, for example, <a href="https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext" rel="nofollow">https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext .
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.
Then again, we'd still have stdint around. And ultimately this doesn't matter because most code isn't portable anyway.
I 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.
I 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.
It 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.
RobotToaster · · focus · HN ↗
Shouldn't they be 64 bits on most modern systems then?
entrope · · focus · HN ↗
Arguably so, but then one would lose the ability to natively name 16-bit integer types because "short" would be 32 bits.
An earlier comment addresses x86-64. AArch64 (pedantically, the A64 instruction set used for AArch64's 64-bit execution mode) is similar, in that addresses are 64 bits wide but ALU instructions typically encode a width bit, called "sf", that selects either 32- or 64-bit data registers and arithmetic. See, for example, <a href="https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext" rel="nofollow">https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext .
imtringued · · focus · HN ↗
Not sure how what you said makes sense.
debugnik · · focus · HN ↗
Then again, we'd still have stdint around. And ultimately this doesn't matter because most code isn't portable anyway.
matvore · · focus · HN ↗
debugnik · · focus · HN ↗
matvore · · focus · HN ↗
It 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.
sparkie · · focus · HN ↗