6

I'm a process of 64 bit, my int size is 8 bytes.

I'm referencing a dll which is compiled to 32 bit.

This dll has a function which accepts an int parameter.

What will happen?

I'm sending a 8 byte to a 4 byte "container" ?

Lieven Keersmaekers
  • 57,207
  • 13
  • 112
  • 146
Royi Namir
  • 144,742
  • 138
  • 468
  • 792
  • 1
    Take a look at [this][1] post. I think this should help u. [1]: http://stackoverflow.com/questions/651956/sizeofint-on-x64 – Tomtom Jun 12 '12 at 07:30
  • IntPtr changes size on the relevant platform, but int doesn't. Due to the very minimal direct pointer use in C#, platform changes are usually transparent in fully managed apps. – Adam Houldsworth Jun 12 '12 at 07:33
  • @AdamHouldsworth so in 64 bit process , int will have the same max value but will "accessed" as 8 byte container ? – Royi Namir Jun 12 '12 at 07:44
  • @RoyiNamir no; you will still be sending 4 bytes to a 4 byte container. At least at the .NET/C# level. What happens *underneath* that (in terms of the CPU registers etc) is an implementation detail. – Marc Gravell Jun 12 '12 at 07:45
  • @RoyiNamir No, I was referring to the `IntPtr` type, which actually does change size (according to its Size property) depending on what CLI is used. As Marc stated in his answer, pointers and references become larger (as they obviously have to accommodate 64-bit address space). – Adam Houldsworth Jun 12 '12 at 07:50
  • @AdamHouldsworth sorry to my misunderstanding , but if im a 64 bit process and im referencing an int ( which i know has max value which can be held in 4 byte) - why my pointer need to be at size of 8 ? i *know* that the int value im referencing can be held at 4 byte , so why im enlarging my reference size ? – Royi Namir Jun 12 '12 at 07:53
  • @RoyiNamir Refer to Marc's comment above, it'll still be 4 bytes. The CLI is responsible for managing the memory of that type when you use it in methods. – Adam Houldsworth Jun 12 '12 at 07:56
  • Could you clarify what you mean by "referencing a dll which is compiled to 32 bit"? Is this DLL a managed assembly with the platform target set to "x86", or is it a native DLL compiled for x86? The two behave quite differently. If, for example, you have managed EXE with platform set to "x64" and it references a managed DLL with platform set to "x86", the latter's platform will be *ignored* and it will be JIT compiled as x64. – Weeble Jun 12 '12 at 08:13

4 Answers4

17

No, in 64-bit / C#, an int is still 4 bytes.

In C#, int is always merely an alias to global::System.Int32

What will change is the reference size and pointer size, but that is all abstracted by the IL anyway - nothing needs to change. Note, though, that the CLI is only going to be 32 bit xor (nand?) 64 bit. You might need one of them to be "Any CPU".

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Hi Marc, can you elaborate on that CLI comment please? – Adam Houldsworth Jun 12 '12 at 07:35
  • The actual process that spawns at runtime is going to have a fixed 32/64 mode. It can't be both. There are separate CLIs for x86 and x64. The relevant CLI will load, but: if one dll is **strictly** x86, and another is **strictly** x64, they may not work well together. "Any CPU" would be far more friendly. – Marc Gravell Jun 12 '12 at 07:37
  • so where is the size of 8 byte enteres here ? (intptr) – Royi Namir Jun 12 '12 at 07:39
  • @Royi it doesn't. Nothing relating to `int` will be 8 bytes. When I mention 32/64 above, I'm talking about the process. – Marc Gravell Jun 12 '12 at 07:44
  • @MarcGravell so why sizeof intptr is 8 (64bit proc)? this is the part which i dont understand....:( – Royi Namir Jun 12 '12 at 07:47
  • The *pointer* size can vary based on the system, but not the size of the INT *value* it points out. – Tigran Jun 12 '12 at 07:48
  • @Marc Oh I see, yes I was aware of that. I was curious if your statement was trying to say something else. Thanks for the clarification. – Adam Houldsworth Jun 12 '12 at 07:48
  • @Tigran so i guess i dont know what is _pointer size_ meaning. – Royi Namir Jun 12 '12 at 07:50
  • @RoyiNamir: pointer is a *data type* by itself that contains *address* to another space, where value is. So the size of the *pointer* depends on the system, but the size of the *field* where the value is, in **this** case remains 4bytes. – Tigran Jun 12 '12 at 07:57
  • @Tigran isnt it a waste ? my reference is a"8 byte" magnitude , but the max value which can held in this region can be stored only as "4 byte" ? – Royi Namir Jun 12 '12 at 08:01
  • 2
    @Royi: it is, but how you gonna manage OS in a way it deals with different pointer sizes, especially in mixed processes, where you can have *only* 64bit data mixed with *only* 32bit data. It becomes mess to manage, if not impossible. Forget about CLR, think about OS design, cause the pointer size is defined by OS and not by CLR. – Tigran Jun 12 '12 at 08:07
  • @Tigran now you made me understand . thanks. ( that was the missing part ) .....:) – Royi Namir Jun 12 '12 at 08:09
  • @RoyiNamir: what do you mean ? – Tigran Jun 12 '12 at 11:13
  • @Tigran i mean : if in 64 bit env , the pointer size to int is 8 byte.....what will be the size of pointer to a short param ? – Royi Namir Jun 12 '12 at 11:36
  • I will be 8, by the way, it is a pointer type, so on 64bit, it is 8. – Tigran Jun 12 '12 at 11:41
3

It always maps to System.Int32 hence would be needing only 4

V4Vendetta
  • 37,194
  • 9
  • 78
  • 82
3

In c# ints are the same size in 32bit and 64bit assemblies. int or Int32 is always 32bit while long or Int64 is always 64bit.

Ral Zarek
  • 1,058
  • 4
  • 18
  • 25
1

int is always 32 bit (4 bytes) in C#, but not in some other languages like C++. System.IntPtr is 4 bytes on an x86 machine and 8 bytes on a 64 bit OS. Use this if you want OS dependend integer types.

bytecode77
  • 14,163
  • 30
  • 110
  • 141