It should indeed, and in hindsight it would have been better to move int to 64 bits (especially for C's integer promotion, which only really makes sense when the promotion happens to the register width.
But porting 32-bit code to 64-bit was a big deal back then, and C99 with its new fixed-width integer types overlapped with the first AMD64 CPUs (and Microsoft's MSVC didn't start to support C99 until around 2015 anyway), I guess keeping int on 32-bits in the popular compilers was deemed 'safer' for porting existing code. I guess we can already be lucky that all the big compilers agreed on the same int width.
I've always believed that they kept 32 bits ints on 64 bits CPU as a default because going full 64 bits would make the code and data structures bigger for "no reason" (it's not often that one hits the 4.10^9 limit in system code (if you don't count timestamps, that is)). For instance, a load-register-with-immediate instruction would normally take 5 bytes (opcode+value) on 32 bits, but 9 bytes on 64.
> would make... data structures bigger for "no reason"
This was the main reason that in stayed 32 bits. Not because larger footprint of structs would be catastrophic — it wouldn't: the 64-bit migration was motivated mainly by the fact that the 32-bit architectures couldn't easily address all that actually existing physical memory past 4 GiB (and virtual memory as well) — but because lots and I mean lots of on-disk data structures were defined in terms of char/short/int, people routinely dumped/gulped their data structures as-is, with no marshalling, so changing the size of int would break literally everything that worked with on-disk data, starting with the filesystem implementations themselves.
RobotToaster · · focus · HN ↗
Shouldn't they be 64 bits on most modern systems then?
flohofwoe · · focus · HN ↗
But porting 32-bit code to 64-bit was a big deal back then, and C99 with its new fixed-width integer types overlapped with the first AMD64 CPUs (and Microsoft's MSVC didn't start to support C99 until around 2015 anyway), I guess keeping int on 32-bits in the popular compilers was deemed 'safer' for porting existing code. I guess we can already be lucky that all the big compilers agreed on the same int width.
astrobe_ · · focus · HN ↗
Joker_vD · · focus · HN ↗
This was the main reason that in stayed 32 bits. Not because larger footprint of structs would be catastrophic — it wouldn't: the 64-bit migration was motivated mainly by the fact that the 32-bit architectures couldn't easily address all that actually existing physical memory past 4 GiB (and virtual memory as well) — but because lots and I mean lots of on-disk data structures were defined in terms of char/short/int, people routinely dumped/gulped their data structures as-is, with no marshalling, so changing the size of int would break literally everything that worked with on-disk data, starting with the filesystem implementations themselves.