When working with process' memory, is there a reason to use uint instead of int?

Question

I mean, from what I understand an int(Int32) will go from -2,147,483,648 to 2,147,483,647. If I recall correctly, every program under windows on 32bits will behave as it has 2gb of ram, so I'd say i can put any address "inside" an int32. Is that true? Or should I stick to uint? I know uint is only for positive integers, and that all memory addresses are positive integers, but my question is more related to "does every memory address fit inside an int32?".

Thanks

edit: from MSDN i can see ReadProcessMemory ( http://msdn.microsoft.com/en-us/library/ms680553%28VS.85%29.aspx ) accepts a size_t argument for the base address. What maps a size_t in .net?

edit2: Ok, now I am kinda confused. Seems that to be 100% safe I should use uints instead of ints. So when using interop, I should using UIntPtrs instead of IntPtrs. But I see everywhere people using IntPtrs. Why is that? Does it have to do that all the things that we use usually are in the first 2gb of memory, so there is no problem in using standard ints?

Answer 1

I believe the limit is 4Gb not 2Gb for 32bit machines/processes. But can be extended if you use AWE. Thus an Int32 would not be appropraite for storing a memory address. But then unless you are doing some form of interop it probably is not appropriate to be directly storing memory addresses.

Edit: Thus for reading a foreign processes Memory, which is a form of interop, I would definitely be using an unsigned integer.

Answer 2

in a 32bit architecture a 32bit pointer can address 4GB of RAM. usually this memory is split 2GB (lower part) is given to the process, while the higher 2GB is given to the OS. You can alter this behaviour by a /3GB switch in boot.ini which will give 3GB to user space and 1GB to OS. So I would strongly recommend using unsigned integers.

Answer 3

Edit: Actually, UIntPtr is not recommended by Microsoft. Switching back to IntPtr. (Research on which was "better" was why it took so long to answer in the first place! :) )

Also, size_t should be mapped to System.IntPtr in .NET. This is because both size_t and System.IntPtr are going to be platform/bitness-dependent. The fact that a size_t is a 32-bit integer is an implementation detail -- by going with System.IntPtr, you effectively future-proof your application. See this StackOverflow question.