Is an int a 64-bit integer in 64-bit C#?

Question

In my C# source code I may have declared integers as:

int i = 5;

or

Int32 i = 5;

In the currently prevalent 32-bit world they are equivalent. However, as we move into a 64-bit world, am I correct in saying that the following will become the same?

int i = 5;
Int64 i = 5;

Dhu

By the by, IntPtr is that kind of structure. See the documentation for the Size property which shines some light on this. – Sufficient

Answer 1

No. The C# specification rigidly defines that int is an alias for System.Int32 with exactly 32 bits. Changing this would be a major breaking change.

Folliculin

Moreover, even in x64, as far as I know, only pointers and size (size_t) are 64bit wide, whereas the default integer is still 32bit wide. – Adhibit

Asaf: In some languages that depends on the compiler. For example, in C++ 64-bit gcc defines long as 64 bits, while Visual C++ keeps long at 32 bits. C# is not such a language, the decision is standardized and not left to the compiler vendor. – Twocolor

Answer 2

The int keyword in C# is defined as an alias for the System.Int32 type and this is (judging by the name) meant to be a 32-bit integer. To the specification:

CLI specification section 8.2.2 (Built-in value and reference types) has a table with the following:

• System.Int32 - Signed 32-bit integer

C# specification section 8.2.1 (Predefined types) has a similar table:

• int - 32-bit signed integral type

This guarantees that both System.Int32 in CLR and int in C# will always be 32-bit.

Baggywrinkle

System.Int64 will be happy to know this. – Qr

Answer 3

Will sizeof(testInt) ever be 8?

No, sizeof(testInt) is an error. testInt is a local variable. The sizeof operator requires a type as its argument. This will never be 8 because it will always be an error.

VS2010 compiles a c# managed integer as 4 bytes, even on a 64 bit machine.

Correct. I note that section 18.5.8 of the C# specification defines sizeof(int) as being the compile-time constant 4. That is, when you say sizeof(int) the compiler simply replaces that with 4; it is just as if you'd said "4" in the source code.

Does anyone know if/when the time will come that a standard "int" in C# will be 64 bits?

Never. Section 4.1.4 of the C# specification states that "int" is a synonym for "System.Int32".

If what you want is a "pointer-sized integer" then use IntPtr. An IntPtr changes its size on different architectures.

Kappel

Answer 4

int is always synonymous with Int32 on all platforms.

It's very unlikely that Microsoft will change that in the future, as it would break lots of existing code that assumes int is 32-bits.

Helpmate

Word to that! MS considers backwards compatability important. Consistency in the language is one of the reasons I <3 C# over C++. – Giselegisella

@Giselegisella I'm with you. Thank the maker that we finally have a C-flavored language that was bold enough to actually define its fundamental datatypes. – Breann

-1 .... that would be an explicit language change which is EXTREMELY unlikely. Exactly this "predetermined" size is one plus of C#. – Tolyl

@TomTom: ...that's what I said. – Helpmate

What about an option in the compiler to compile to 32 or 64 bits integers? – Revolutionist

@Xavier: I don't think that would be such a good idea, because (1) it would increase the probability of compiling code incorrectly. You could no longer look at the source code alone and know how wide int is meant to be. You'd have to also specify how code is to be compiled, which could mean that (2) your source code becomes dependent on a particular compiler. (Remember, while the C# language is standardised, compiler switches and options usually aren't.) – Composite

Answer 5

I think what you may be confused by is that int is an alias for Int32 so it will always be 4 bytes, but IntPtr is suppose to match the word size of the CPU architecture so it will be 4 bytes on a 32-bit system and 8 bytes on a 64-bit system.

Pen

Answer 6

According to the C# specification ECMA-334, section "11.1.4 Simple Types", the reserved word int will be aliased to System.Int32. Since this is in the specification it is very unlikely to change.

Goiter

Answer 7

No matter whether you're using the 32-bit version or 64-bit version of the CLR, in C# an int will always mean System.Int32 and long will always mean System.Int64.

Colobus

Answer 8

The following will always be true in C#:

sbyte signed 8 bits, 1 byte

byte unsigned 8 bits, 1 byte

short signed 16 bits, 2 bytes

ushort unsigned 16 bits, 2 bytes

int signed 32 bits, 4 bytes

uint unsigned 32 bits, 4 bytes

long signed 64 bits, 8 bytes

ulong unsigned 64 bits, 8 bytes

An integer literal is just a sequence of digits (eg 314159) without any of these explicit types. C# assigns it the first type in the sequence (int, uint, long, ulong) in which it fits. This seems to have been slightly muddled in at least one of the responses above.

Weirdly the unary minus operator (minus sign) showing up before a string of digits does not reduce the choice to (int, long). The literal is always positive; the minus sign really is an operator. So presumably -314159 is exactly the same thing as -((int)314159). Except apparently there's a special case to get -2147483648 straight into an int; otherwise it'd be -((uint)2147483648). Which I presume does something unpleasant.

Somehow it seems safe to predict that C# (and friends) will never bother with "squishy name" types for >=128 bit integers. We'll get nice support for arbitrarily large integers and super-precise support for UInt128, UInt256, etc. as soon as processors support doing math that wide, and hardly ever use any of it. 64-bit address spaces are really big. If they're ever too small it'll be for some esoteric reason like ASLR or a more efficient MapReduce or something.

Turn

Answer 9

Yes, as Jon said, and unlike the 'C/C++ world', Java and C# aren't dependent on the system they're running on. They have strictly defined lengths for byte/short/int/long and single/double precision floats, equal on every system.

Goins

In the C/C++ world, ints are dependent on the compiler rather than the underlying hardware. Most 64-bit C++ compilers still use 32-bit ints, but pointers will be 64-bit instead of 32. – Stannum

And in the C world, they actually ran out of confidence in the whole scheme at C99 and decided not to make long get any longer but to add long long instead. At some level this is an acknowledgement that types with unpredictable (over extended time-scales) sizes are a problem. – Minion

Answer 10

int without suffix can be either 32bit or 64bit, it depends on the value it represents.

as defined in MSDN:

When an integer literal has no suffix, its type is the first of these types in which its value can be represented: int, uint, long, ulong.

Here is the address: https://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx

Staphylococcus

That is incorrect, the source is being misinterpreted. It is talking about integer literals, while int is always 32 bits long. – Sternick