3 ms·

> I find it weird that the convention to use char/short/int/long/long long has persisted so widely to this day. I don't think this is a reasonable take. Beyond

> I find it weird that the convention to use char/short/int/long/long long has persisted so widely to this day. I don't think this is a reasonable take. Beyond ABI requirements and how developers use int over short, there are indeed requirements where the size of an integer value matters a lot, specially as this has a direct impact on data size and vectorization. To frame your analysis, I would recommend you took a peek at the not-so-recent push for hardware support for IEEE754 half-precision float/float16 types.

zokier 2y ago
The cases where you want platform-specific integer width (that is not something like size_t/uintptr_t) is extremely niche compared to cases where you want integer to have specific width. I don't see the relation to fp16; I don't think anyone is pushing for `float` to refer to fp16 (or fp64 for that matter) anywhere. `long double` is already bad enough.
- manwe150 2y ago
  My recollection of history is that the standardization of stdint.h happened long after the transition to 32 bit, and is only just finishing up becoming available on some major compilers after the transition to 64 bit is well behind us
  - jcranmer 2y ago
    stdint.h was introduced in C99, and MSVC didn't introduce it until 2010.
  - layer8 2y ago
    You could fairly easily create your own portable stdint.h equivalent in C89 (using the preprocessor and INT_MAX etc.). I remember doing that in the 90s, before C99. However, it was also conventional wisdom to use int by default to match the architecture’s “natural” word size, and maybe add a preprocessor check when you needed it to be 32-bit. Another consideration is that the built-in types have to be used with the C standard library functions to some extent.
- chipdart 2y ago
  > The cases where you want platform-specific integer width (that is not something like size_t/uintptr_t) is extremely niche (...) I think you got it backwards. There are platform-specific ints because different processors have different word sizes. Programing languages then adjust their definitions for these word sizes because they are handled naturally by specific processors. So differences in word sizes exist between processors. Either programming languages support them, or they don't. Also, there is also specific needs to handle specific int sizes regardless of cpu architecture. Either programming languages support them, or don't. And you end with "platform-specific integer widths" because programming languages do the right thing and support them.
  - zokier 2y ago
    The fact that we have all these different 64 bit data models demonstrates clearly how the connection between word size and C types is completely arbitrary and largely meaningless. And this is not specific to 64 bit either, same sort of thing happens on 8 bit platforms too. So you can not rely on `int` (or any other type) being word sized. Furthermore I argue that word size is not really something that makes sense to even expose at language level, the whole concept of word size is somewhat questionable. CPUs operate on all sort of things that can have different sizes, trying to reduce that to single "word size" is futile.

zokier 2y ago

The cases where you want platform-specific integer width (that is not something like size_t/uintptr_t) is extremely niche compared to cases where you want integer to have specific width. I don't see the relation to fp16; I don't think anyone is pushing for `float` to refer to fp16 (or fp64 for that matter) anywhere. `long double` is already bad enough.

manwe150 2y ago
My recollection of history is that the standardization of stdint.h happened long after the transition to 32 bit, and is only just finishing up becoming available on some major compilers after the transition to 64 bit is well behind us
- jcranmer 2y ago
  stdint.h was introduced in C99, and MSVC didn't introduce it until 2010.
- layer8 2y ago
  You could fairly easily create your own portable stdint.h equivalent in C89 (using the preprocessor and INT_MAX etc.). I remember doing that in the 90s, before C99. However, it was also conventional wisdom to use int by default to match the architecture’s “natural” word size, and maybe add a preprocessor check when you needed it to be 32-bit. Another consideration is that the built-in types have to be used with the C standard library functions to some extent.
chipdart 2y ago
> The cases where you want platform-specific integer width (that is not something like size_t/uintptr_t) is extremely niche (...) I think you got it backwards. There are platform-specific ints because different processors have different word sizes. Programing languages then adjust their definitions for these word sizes because they are handled naturally by specific processors. So differences in word sizes exist between processors. Either programming languages support them, or they don't. Also, there is also specific needs to handle specific int sizes regardless of cpu architecture. Either programming languages support them, or don't. And you end with "platform-specific integer widths" because programming languages do the right thing and support them.
- zokier 2y ago
  The fact that we have all these different 64 bit data models demonstrates clearly how the connection between word size and C types is completely arbitrary and largely meaningless. And this is not specific to 64 bit either, same sort of thing happens on 8 bit platforms too. So you can not rely on `int` (or any other type) being word sized. Furthermore I argue that word size is not really something that makes sense to even expose at language level, the whole concept of word size is somewhat questionable. CPUs operate on all sort of things that can have different sizes, trying to reduce that to single "word size" is futile.