On a system, does data type "int" in C always have the same number of bits as the bits of the OS?
Thanks!
On a system, does data type "int" in C always have the same number of bits as the bits of the OS?
Thanks!
No, not necessarily. Just for an obvious example, if you use a 32-bit compiler on a 64-bit OS, you'll typically have 32-bit int
s.
The requirements in the C standard are fairly minimal. Beyond the minimum size requirements, there's (§6.2.5/5):
A ‘‘plain’’
int
object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the rangeINT_MIN
toINT_MAX
as defined in the header<limits.h>
).
If you need to be certain that your type is at least 64 bits, you can use long long
.
Types like int32_t
have been mentioned in other answers. Although often used for other purposes, this type is really intended for a situation where you need a type that's exactly 32-bits wide, regardless of how that may impact performance.
That means you generally want to avoid these types. If you just need to ensure that you can hold at least a 64-bit integer without overflow, either long long
or int_fast64_t
is a better choice (and likewise for things like 32-bit types). Right now, for a 64-bit type, it's unlike this will make a big difference for a 64-bit type.
For a 32-bit type (for example) it might well make a difference though. int32_t
must be exactly 32 bits wide, but in a 64-bit process on a 64-bit OS running on a 64-bit processor, it's quite likely that a 64-bit type will be faster than a 32-bit type. I've roughly tripled the speed of some legacy (but not terribly old) code that used int32_t
where it wasn't really suitable. At the time (on a 32-bit compiler and OS) it didn't cause a problem, but on a 64-bit system, it imposed a fair amount of extra work, because what they really wanted was int_fast32_t
--the fastest type available that supported at least 32 bits.
Likewise, it seems nearly inevitable that at some point in the future, we'll start to use processors "larger" than 64 bits. When we do, we'll probably hit the same situation with 64-bit types that we have right now with 32-bit types: there'll be quite a few places that people have used int64_t
when they probably wanted int_fast64_t
, and their code will run substantially slower than it really needs to because they've required their (for example) 128-bit processor to mask the operand(s) down to 64 bits instead of working with the size native to the processor.
No. It will depend on the OS and the architecture (ie: what type of processor running the OS). Common primitive types like int
, unsigned
, etc will be system dependent, so depending on the system you are using, int
could be 16, 32, or some arbitrary size.
If you want to guarantee the size of a value, you need to use fixed-width types. If you want to do that, look into <stdint.h>
, and the new primitives it provides you with, like int32_t
, uint8_t
, etc.
References
<http://www.cplusplus.com/reference/cstdint/>
It's not required to by the standard. It may in practice usually, but this thread mentions that it's more commonly false in embedded systems.
On a 64-bit Debian, this small program
#include <stdio.h>
int main() {
#define printSize(aType) printf("sizeof " #aType " = %ld\n", sizeof(aType))
printSize(void*);
printSize(char);
printSize(short);
printSize(int);
printSize(long);
printSize(long long);
}
prints the following:
sizeof void* = 8
sizeof char = 1
sizeof short = 2
sizeof int = 4
sizeof long = 8
sizeof long long = 8
So it's not just that int
is not required to be 64 bits on a 64 bit system, there is also real world general purpose systems on which the size of int
defers from the pointer size. Consequently, you should not rely on the size of these types.
There are exceptions to this rule, where you can rely on the size of a basic type. These are explicitly mentioned in the C standard. The two most important ones are these:
char
is required to be one 8 bit (you can't count on it being either signed or unsigned, though).
long long
is required to be at least 64 bits.
And of course, long
is required to be at least as big as int
etc.