Thread

C's Flexible Integer Sizes Were Not a Design Mistake

113 points · 166 comments · ibobev

RobotToaster · 1790499966 · focus · HN ↗
> A 'plain' int object has the natural size suggested by the architecture of the execution environment.
Shouldn't they be 64 bits on most modern systems then?
1. entrope · 1790503241 · focus · HN ↗
  > 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 .
  1. imtringued · 1790505503 · focus · 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.
    debugnik · 1790538726 · focus · HN ↗
    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.
    matvore · 1790539379 · focus · HN ↗
    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.
    [deleted] · 1790539505 · focus · HN ↗
    [deleted]

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.