Does the Size of an Int Depend on the Compiler And/Or Processor

Does the size of an int depend on the compiler and/or processor?

The answer to this question depends on how far from practical considerations we are willing to get.

Ultimately, in theory, everything in C and C++ depends on the compiler and only on the compiler. Hardware/OS is of no importance at all. The compiler is free to implement a hardware abstraction layer of any thickness and emulate absolutely anything. There's nothing to prevent a C or C++ implementation from implementing the int type of any size and with any representation, as long as it is large enough to meet the minimum requirements specified in the language standard. Practical examples of such level of abstraction are readily available, e.g. programming languages based on "virtual machine" platform, like Java.

However, C and C++ are intended to be highly efficient languages. In order to achieve maximum efficiency a C or C++ implementation has to take into account certain considerations derived from the underlying hardware. For that reason it makes a lot of sense to make sure that each basic type is based on some representation directly (or almost directly) supported by the hardware. In that sense, the size of basic types do depend on the hardware.

In other words, a specific C or C++ implementation for a 64-bit hardware/OS platform is absolutely free to implement int as a 71-bit 1's-complement signed integral type that occupies 128 bits of memory, using the other 57 bits as padding bits that are always required to store the birthdate of the compiler author's girlfriend. This implementation will even have certain practical value: it can be used to perform run-time tests of the portability of C/C++ programs. But that's where the practical usefulness of that implementation would end. Don't expect to see something like that in a "normal" C/C++ compiler.

What determines the size of integer in C?

Ultimately the compiler does, but in order for compiled code to play nicely with system libraries, most compilers match the behavior of the compiler[s] used to build the target system.

So loosely speaking, the size of int is a property of the target hardware and OS (two different OSs on the same hardware may have a different size of int, and the same OS running on two different machines may have a different size of int; there are reasonably common examples of both).

All of this is also constrained by the rules in the C standard. int must be large enough to represent all values between -32767 and 32767, for example.

integer size in c depends on what?

It's implementation-dependent. The C standard only requires that:

• char has at least 8 bits
• short has at least 16 bits
• int has at least 16 bits
• long has at least 32 bits
• long long has at least 64 bits (added in 1999)
• sizeof(char) ≤ sizeof(short) ≤ sizeof(int) ≤ sizeof(long) ≤ sizeof(long long)

In the 16/32-bit days, the de facto standard was:

• int was the "native" integer size
• the other types were the minimum size allowed

However, 64-bit systems generally did not make int 64 bits, which would have created the awkward situation of having three 64-bit types and no 32-bit type. Some compilers expanded long to 64 bits.

Does the size of data types in C depend on the OS?

Yes. This is precisely what is meant by "platform-specific definitions" for things like the size of int and the meaning of system calls.

They depend not just on the OS, but also on the target hardware and compiler configuration.

Who decides the sizeof any datatype or structure (depending on 32 bit or 64 bit)?

It's ultimately the compiler. The compiler implementors can decide to emulate whatever integer size they see fit, regardless of what the CPU handles the most efficiently. That said, the C (and C++) standard is written such, that the compiler implementor is free to choose the fastest and most efficient way. For many compilers, the implementers chose to keep int as a 32 bit, although the CPU natively handles 64 bit ints very efficiently.

I think this was done in part to increase portability towards programs written when 32 bit machines were the most common and who expected an int to be 32 bits and no longer. (It could also be, as user user3386109 points out, that 32 bit data was preferred because it takes less space and therefore can be accessed faster.)

So if you want to make sure you get 64 bit ints, you use int64_t instead of int to declare your variable. If you know your value will fit inside of 32 bits or you don't care about size, you use int to let the compiler pick the most efficient representation.

_{As for the other datatypes such as struct, they are composed from the base types such as int.}

Does the size of the integer or any other data types in C dependent on the underlying architecture?

see here:
size guarantee for integral/arithmetic types in C and C++

Fundamental C type sizes are depending on implementation (compiler) and architecture, however they have some guaranteed boundaries. One should therefore never hardcode type sizes and instead use sizeof(TYPENAME) to get their length in bytes.

Why does sizeof(int) vary across different operating systems?

According to the C++ standard

1.7.1 states:

The fundamental storage unit in the C++ memory model is the byte. A
byte is at least large enough to contain any member of the basic
execution character set ...

then 3.9.1.1 states:

Objects declared as characters (char) shall be large enough to store
any member of the implementation’s basic character set.

So we can infer that char is actually a byte. Most importantly 3.9.1.2 also says:

There are five signed integer types: “signed char”, “short int”, “int”,
“long int”, and “long long int”. In this list, each type provides at
least as much storage as those preceding it in the list. Plain ints
have the natural size suggested by the architecture of the execution
environment; the other signed integer types are provided to meet
special needs.

So in other words the size of int is (a) guaranteed to be at least a byte and (b) naturally aligned to the OS/hardware it's running on so most likely these days to be 64 bit or (for many older systems) 32 bit.

Why sizeof built in types except char is compiler dependent in C & C++?

The reason is largely because C is portable to a much wider variety of platforms. There are many reasons why the different data types have turned out to be the various sizes they are on various platforms, but at least historically, int has been adapted to be the platform's native word size. On the PDP-11 it was 16 bits (and long was originally invented for 32-bit numbers), while some embedded platform compilers even have 8-bit ints. When 32-bit platforms came around and started having 32-bit ints, short was invented to represent 16-bit numbers.

Nowadays, most 64-bit architectures use 32-bit ints simply to be compatible with the large base of C programs that were originally written for 32-bit platforms, but there have been 64-bit C compilers with 64-bit ints as well, not least of which some early Cray platforms.

Also, in the earlier days of computing, floating-point formats and sizes were generally far less standardized (IEEE 754 didn't come around until 1985), which is why floats and doubles are even less well-defined than the integer data types. They generally don't even presume the presence of such peculiarities as infinities, NaNs or signed zeroes.

Furthermore, it should perhaps be said that a char is not defined to be 1 byte, but rather to be whatever sizeof returns 1 for. Which is not necessarily 8 bits. (For completeness, it should perhaps be added here, also, that "byte" as a term is not universally defined to be 8 bits; there have been many historical definitions of it, and in the context of the ANSI C standard, a "byte" is actually defined to be the smallest unit of storage that can store a char, whatever the nature of char.)

There are also such architectures as the 36-bit PDP-10s and 18-bit PDP-7s that have also run C programs. They may be quite rare these days, but do help explain why C data types are not defined in terms of 8-bit units.

Whether this, in the end, really makes the language "more portable" than languages like Java can perhaps be debated, but it would sure be suboptimal to run Java programs on 16-bit processors, and quite weird indeed on 36-bit processors. It is perhaps fair to say that it makes the language more portable, but programs written in it less portable.

EDIT: In reply to some of the comments, I just want to append, as an opinion piece, that C as a language is unlike languages like Java/Haskell/ADA that are more-or-less "owned" by a corporation or standards body. There is ANSI C, sure, but C is more than ANSI C; it's a living community, and there are many implementations that aren't ANSI-compatible but are "C" nevertheless. Arguing whether implementations that use 8-bit ints are C is similar to arguing whether Scots is English in that it's mostly pointless. They use 8-bit ints for good reasons, noone who knows C well enough would be unable to reason about programs written for such compilers, and anyone who writes C programs for such architectures would want their ints to be 8 bits.

Is Variable size in C compiler dependent?

arr[], as a function parameter, is a pointer. sizeof(arr)/sizeof(arr[0]); is the size of a pointer/size of of an int. No arrays involved.

Is Variable size in C compiler dependent?

Yes, an int could be 32-bit, 16-bit, etc.¹ (Must be at least 16)

An object pointer could be 16-bit, 32-bit, 64-bit, or etc.¹ (Must be at least 16)

A pointer is often wider than an int, yet could be the same or (rarely) less. The ratio could be 2/1 or 1/1 or others.

---

¹ Other sizes are possible and have been employed such as 36-bit int or 48-bit object pointer. This is C's ability to adopt to just about any processor ever built and likely to all new ones. The flexibility comes at the expense that portable code must account for these variations.

---

Related Topics