Hacker News Reader

Comment by entrope | Hacker News Reader

> 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, https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext .

View on HN

char is at least 8 bits, short is at least 16 bits, long is at least 32 bits, long long is at least 64 bits.

Not sure how what you said makes sense.

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.

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.

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.

Yeah, in GCC for example, we can define exact width types without including `<stdint.h>`.

    typedef unsigned __attribute__((mode(HI))) uint16_t;
    typedef signed __attribute__((mode(SI))) int32_t;

Of course, the mode needs to be supported by the compiler for the target arch, but we don't need to include anything.

Reply on news.ycombinator.com