6 ms·

Well, there is an argument to be had that, for C, a plain unadorned "int" should probably be the native word size for that architecture. On 64-bit systems, "int

Well, there is an argument to be had that, for C, a plain unadorned "int" should probably be the native word size for that architecture. On 64-bit systems, "int" would therefore also be 64 bits.

_kst_ 3y ago
I think there are two reasons int has not gone from 32 to 64 bits on 64-bit systems. Part of it is backward compatibility: code written to assume 32-bit int could break. (Arguably such code is badly written, but breaking it would still be inconvenient.) Another part is that C has a limited number of predefined integer types; char, short, int, long, long long (plus unsigned variants and signed char). If char is 8 bits and int is 64 bits, then you can't have both a 16-bit and a 32-bit integer type. Extended integer types (introduced in C99) could address this, but I don't know of any compilers that provide them.
- myrmidon 3y ago
  > Extended integer types (introduced in C99) could address this, but I don't know of any compilers that provide them. What environment are you working in? Because I don't know a single half-recent compiler that does not provide stdint (uint8_t, ..., int64_t), but I mostly work with GCC/LLVM toolchains.
  - retrac 3y ago
    Some embedded compilers will provide stdint. And if the compiler doesn't, I've found that one of the first headers written for a project ends up being an equivalent to stdint. It's pretty common to develop part of an embedded C program under Linux or similar host environment. Better debuggers, better profiling tools, etc. And uint8_t and friends are particularly important when you're working cross-platform.
  - dzaima 3y ago
    Extended integer types aren't necessarily related to stdint.h - in the vast majority if not every one of those "half-decent compilers" the stdint.h types are just typedefs over plain old char/short/int/long/long long, which are not extended integer types. Extended integer types is a mechanism to allow having types other than those.
    - myrmidon 3y ago
      > in the vast majority if not every one of those "half-decent compilers" the stdint.h types are just typedefs over plain old char/short/int/long/long long, which are not extended integer types. Sure, but isn't that just an implementation detail? Because I really don't care if my int64_t is internally typedef'd to "long long int" or "__m64", as long as there is a standardized interface to ask for it.
      - dzaima 3y ago
        Point being, _kst_'s comment of "I don't know of any compilers that provide them" is correct - there are few if any compilers that actually have actual extended integer types, and thus introducing such in compilers might be non-trivial, and plenty of code may exist under the assumption that they don't exist and thus could break (things like integer promotion rules, _Generic, varargs; and also intmax_t is of mention as it must be at least as wide as any supported standard or extended integer type (which is also why clang/gcc __int128 doesn't qualify as an integer type as per the standard))
- bewaretheirs 3y ago
  If you can have "long long", why not "short short"? In that alternate universe, char could be 8 bits, short short 16, short 32, and int 64.
  - cpeterso 3y ago
    And “long short” and “short long” types. :)
    - travisgriggs 3y ago
      For 24 bits?
- stkdump 3y ago
  Since the extended integer types are just aliases to the other types, they wouldn't solve the problem. Also in C++ these aliases create a problem with overload sets when you mix the two worlds and try to produce portable code. For example long on some platforms is 32 bit and 64 bit on others, also platforms use inconsistent fundamental types for 32 and 64 bit aliases. All in all if you want to produce portable code you neither use those extended integer types nor long. You assume char, short, int, long long are 8, 16, 32, 64 bit respectively, which holds on all relevant platforms.
  - dzaima 3y ago
    Extended integer types are decidedly not just aliases to other types - the C standard has separate "standard integer types" which are the regular char/short/int/long/long long, and "extended integer types" which are any additional implementation-specific types. stdint.h-defined types can be either of those categories (and on regular clang/gcc they're all standard integer types and not extended ones). So you could have a system with char/short/int/long/long long being 8/16/64/64/64-bit respectively and still be able to provide an int32_t that's none of those; just, noone does.
    - dataflow 3y ago
      What really sucks about this in C++ is that it prevents you from knowing whether you can overload based on those types.
hgs3 3y ago
I was always a little surprised C never had an integer type the size of a native word. Probably the closest thing would be intptr_t since pointers presumably use a single word to represent addressable memory.
- WalterBright 3y ago
  size_t and ptrdiff_t works for me.
- gumby 3y ago
  It did on the PDP-11
- zozbot234 3y ago
  > pointers presumably use a single word to represent addressable memory. Only in flat address spaces, which excludes platforms like old 16-bit x86 or modern CHERI. There, "pointer difference within a single object" need not be the same size as "pointer reference".
- flohofwoe 3y ago
  AFAIK until the switch to 64-bit architectures, int actually was the natural word size. Keeping int at 32-bits was probably done to simplify porting code to 64-bits (since all structs with ints in them would change their memory layout - but that's what the fixed-width integer types are for anyway, e.g. int32_t). In hindsight it would probably have been better to bite the bullet and make int 64 bits wide.
  - garaetjjte 3y ago
    int being originally native word size is the reason for weird integer promotion rules.
    - flohofwoe 3y ago
      IMHO it's only weird because the promotion is to 32-bit integers on 64-bit platforms. If all math would happen on the natural word size (e.g. 64-bits), and specific integer widths would only matter for memory loads/stores, it would be fine.
WalterBright 3y ago
Yeah, except that ints in your data structures will unnecessarily consume far, far too much memory.
- flohofwoe 3y ago
  OTH, the explicitly sized integers (int32_t, int16_t etc) had been added already in C99 (e.g. 25 years ago), and should be used when a specific memory layout of structs is desired.
  - WalterBright 3y ago
    If you're going to use those, then there's no reason to have ints be 64 bit. Personally, I find using int32_t in general to be an uglification of the code. I never use `long` in C code anymore, as it's sometimes 32 bits and sometimes 64 bits. I use `int` and `long long`. Do I care about 16 bit code anymore? No. Very few programs would port between 16/32 these days anyway, no matter what the Standard says or how hard you try to write code portably.
    - extraduder_ire 3y ago
      Always thought it was odd how "long long" is one of the only common types that's two words with an implicit int at the end. Almost makes me want to add "typedef long long longer;" to some code that I don't intend anyone to maintain.
    - cpeterso 3y ago
      Google’s C++ style guide similarly recommends using ‘int’ in general and never using ‘int32_t’, though it recommends using ‘int64_t’ for bigger numbers instead of ‘long’: https://google.github.io/styleguide/cppguide.html#Integer_Types https://google.github.io/styleguide/cppguide.html#Integer_Ty...
    - LeFantome 3y ago
      Is it the numbers you do not like? If you use “long long”, it must not be the length. I don’t love long long. As an amateur compiler writer, it hurts me. “long long” makes “long” both a modifier ( like unsigned is ) and a type. Yuck. I wish it was i8, i16, i32, and i64 ( with u versions of each ). f32 and f64 for floats. Those are easy to understand and fairly easy on the eyes. If those numbers are too noisy, the CIL ( .NET ) types could work. For example, i4 and i8 instead of i32 and i64. I do no love the look of i1 either though. I guess you could special case sbyte and byte as aliases.
bee_rider 3y ago
If the programmer didn’t specify the size of an int, it should mean “dealer’s choice.” Let the compiler pick a default, better yet make it a compiler option. Fortran is, as always, ahead of the game.
- pklausler 3y ago
  “as always”?
  - bee_rider 3y ago
    I think you accidentally put a question mark where you meant to put an exclamation point.
- Conscat 3y ago
  It is a compiler setting. `-Dint=__INT64_TYPE__`
fweimer 3y ago
I would argue that the native word size is still 32 bits on x86-64, though. With many instructions, using 64-bit registers needs a segment prefix override. Some RISC architectures do not even have 32-bit zero-extending integer instructions, so for them, 64-bit as the native word size makes sense. On the other hand, I'm not sure if <stdint.h> and uint16_t were invented at the time, and “short short int“ is not valid syntax (even today), so there wasn't an obvious way to denote a 16-bit integer type.

Well, there is an argument to be had that, for C, a plain unadorned "int" should probably be the native word size for that architecture. On 64-bit systems, "int" would therefore also be 64 bits.

_kst_ 3y ago

I think there are two reasons int has not gone from 32 to 64 bits on 64-bit systems. Part of it is backward compatibility: code written to assume 32-bit int could break. (Arguably such code is badly written, but breaking it would still be inconvenient.) Another part is that C has a limited number of predefined integer types; char, short, int, long, long long (plus unsigned variants and signed char). If char is 8 bits and int is 64 bits, then you can't have both a 16-bit and a 32-bit integer type. Extended integer types (introduced in C99) could address this, but I don't know of any compilers that provide them.

myrmidon 3y ago
> Extended integer types (introduced in C99) could address this, but I don't know of any compilers that provide them. What environment are you working in? Because I don't know a single half-recent compiler that does not provide stdint (uint8_t, ..., int64_t), but I mostly work with GCC/LLVM toolchains.
- retrac 3y ago
  Some embedded compilers will provide stdint. And if the compiler doesn't, I've found that one of the first headers written for a project ends up being an equivalent to stdint. It's pretty common to develop part of an embedded C program under Linux or similar host environment. Better debuggers, better profiling tools, etc. And uint8_t and friends are particularly important when you're working cross-platform.
- dzaima 3y ago
  Extended integer types aren't necessarily related to stdint.h - in the vast majority if not every one of those "half-decent compilers" the stdint.h types are just typedefs over plain old char/short/int/long/long long, which are not extended integer types. Extended integer types is a mechanism to allow having types other than those.
  - myrmidon 3y ago
    > in the vast majority if not every one of those "half-decent compilers" the stdint.h types are just typedefs over plain old char/short/int/long/long long, which are not extended integer types. Sure, but isn't that just an implementation detail? Because I really don't care if my int64_t is internally typedef'd to "long long int" or "__m64", as long as there is a standardized interface to ask for it.
    - dzaima 3y ago
      Point being, _kst_'s comment of "I don't know of any compilers that provide them" is correct - there are few if any compilers that actually have actual extended integer types, and thus introducing such in compilers might be non-trivial, and plenty of code may exist under the assumption that they don't exist and thus could break (things like integer promotion rules, _Generic, varargs; and also intmax_t is of mention as it must be at least as wide as any supported standard or extended integer type (which is also why clang/gcc __int128 doesn't qualify as an integer type as per the standard))
bewaretheirs 3y ago
If you can have "long long", why not "short short"? In that alternate universe, char could be 8 bits, short short 16, short 32, and int 64.
- cpeterso 3y ago
  And “long short” and “short long” types. :)
  - travisgriggs 3y ago
    For 24 bits?
stkdump 3y ago
Since the extended integer types are just aliases to the other types, they wouldn't solve the problem. Also in C++ these aliases create a problem with overload sets when you mix the two worlds and try to produce portable code. For example long on some platforms is 32 bit and 64 bit on others, also platforms use inconsistent fundamental types for 32 and 64 bit aliases. All in all if you want to produce portable code you neither use those extended integer types nor long. You assume char, short, int, long long are 8, 16, 32, 64 bit respectively, which holds on all relevant platforms.
- dzaima 3y ago
  Extended integer types are decidedly not just aliases to other types - the C standard has separate "standard integer types" which are the regular char/short/int/long/long long, and "extended integer types" which are any additional implementation-specific types. stdint.h-defined types can be either of those categories (and on regular clang/gcc they're all standard integer types and not extended ones). So you could have a system with char/short/int/long/long long being 8/16/64/64/64-bit respectively and still be able to provide an int32_t that's none of those; just, noone does.
  - dataflow 3y ago
    What really sucks about this in C++ is that it prevents you from knowing whether you can overload based on those types.

hgs3 3y ago

I was always a little surprised C never had an integer type the size of a native word. Probably the closest thing would be intptr_t since pointers presumably use a single word to represent addressable memory.

WalterBright 3y ago
size_t and ptrdiff_t works for me.
gumby 3y ago
It did on the PDP-11
zozbot234 3y ago
> pointers presumably use a single word to represent addressable memory. Only in flat address spaces, which excludes platforms like old 16-bit x86 or modern CHERI. There, "pointer difference within a single object" need not be the same size as "pointer reference".
flohofwoe 3y ago
AFAIK until the switch to 64-bit architectures, int actually was the natural word size. Keeping int at 32-bits was probably done to simplify porting code to 64-bits (since all structs with ints in them would change their memory layout - but that's what the fixed-width integer types are for anyway, e.g. int32_t). In hindsight it would probably have been better to bite the bullet and make int 64 bits wide.
- garaetjjte 3y ago
  int being originally native word size is the reason for weird integer promotion rules.
  - flohofwoe 3y ago
    IMHO it's only weird because the promotion is to 32-bit integers on 64-bit platforms. If all math would happen on the natural word size (e.g. 64-bits), and specific integer widths would only matter for memory loads/stores, it would be fine.

WalterBright 3y ago

Yeah, except that ints in your data structures will unnecessarily consume far, far too much memory.

flohofwoe 3y ago
OTH, the explicitly sized integers (int32_t, int16_t etc) had been added already in C99 (e.g. 25 years ago), and should be used when a specific memory layout of structs is desired.
- WalterBright 3y ago
  If you're going to use those, then there's no reason to have ints be 64 bit. Personally, I find using int32_t in general to be an uglification of the code. I never use `long` in C code anymore, as it's sometimes 32 bits and sometimes 64 bits. I use `int` and `long long`. Do I care about 16 bit code anymore? No. Very few programs would port between 16/32 these days anyway, no matter what the Standard says or how hard you try to write code portably.
  - extraduder_ire 3y ago
    Always thought it was odd how "long long" is one of the only common types that's two words with an implicit int at the end. Almost makes me want to add "typedef long long longer;" to some code that I don't intend anyone to maintain.
  - cpeterso 3y ago
    Google’s C++ style guide similarly recommends using ‘int’ in general and never using ‘int32_t’, though it recommends using ‘int64_t’ for bigger numbers instead of ‘long’: https://google.github.io/styleguide/cppguide.html#Integer_Types https://google.github.io/styleguide/cppguide.html#Integer_Ty...
  - LeFantome 3y ago
    Is it the numbers you do not like? If you use “long long”, it must not be the length. I don’t love long long. As an amateur compiler writer, it hurts me. “long long” makes “long” both a modifier ( like unsigned is ) and a type. Yuck. I wish it was i8, i16, i32, and i64 ( with u versions of each ). f32 and f64 for floats. Those are easy to understand and fairly easy on the eyes. If those numbers are too noisy, the CIL ( .NET ) types could work. For example, i4 and i8 instead of i32 and i64. I do no love the look of i1 either though. I guess you could special case sbyte and byte as aliases.

bee_rider 3y ago

If the programmer didn’t specify the size of an int, it should mean “dealer’s choice.” Let the compiler pick a default, better yet make it a compiler option. Fortran is, as always, ahead of the game.

pklausler 3y ago
“as always”?
- bee_rider 3y ago
  I think you accidentally put a question mark where you meant to put an exclamation point.
Conscat 3y ago
It is a compiler setting. `-Dint=__INT64_TYPE__`

fweimer 3y ago

I would argue that the native word size is still 32 bits on x86-64, though. With many instructions, using 64-bit registers needs a segment prefix override. Some RISC architectures do not even have 32-bit zero-extending integer instructions, so for them, 64-bit as the native word size makes sense. On the other hand, I'm not sure if <stdint.h> and uint16_t were invented at the time, and “short short int“ is not valid syntax (even today), so there wasn't an obvious way to denote a 16-bit integer type.