>This is a deliberate design statement. int was never meant to be "32 bits". It meant "whatever this machine is fastest and most comfortable with".
This is the issue with how people talk about C. int is basically the signed version of size_t aka a word sized data type. It's not meant to have a fixed size.
When people want the classic 4 byte data type they should choose long instead.
> int is basically the signed version of size_t aka a word sized data type. It's not meant to have a fixed size.
It isn't. `int` is at least as large as `short` and at least 16-bits. On modern systems `int` is still typically 32-bits whereas `size_t` is typically 64-bits. There's a `ssize_t` in POSIX for signed sizes.
> When people want the classic 4 byte data type they should choose long instead.
`long` is only at least 4 bytes, and at least as large as `int`. On MSVC (LLP64 data model) it's 4 bytes, but on SYSV (LP64 data model) it's 8 bytes. `long` should almost never be used if you actually want portable code today.
`int` is 32-bits and `long long` is 64-bits on both LP64 and LLP64. If you want portable code using the native integer types, these are the ones you should use, definitely not `long`.
I am not a C developer but I used to think that there was some sanity in the design. Now that residual sanity I thought was left in C has faded away. I retract all my comments in this HN submission that defend C. Whenever anyone reads them, they should consider them made erroneously in good faith by a person who wanted to justify some of the weird decisions made in C but it turns out they were just plain silly.
Edit: actually now that I think about I'm willing to extend goodwill to C retroactively if sparkie retracts his silly nitpick and makes it charitable instead.
This is the issue with how people talk about C. int is basically the signed version of size_t aka a word sized data type. It's not meant to have a fixed size.
When people want the classic 4 byte data type they should choose long instead.