0

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(VS.85).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?

devoured elysium
  • 101,373
  • 131
  • 340
  • 557
  • 1
    This answers your question regarding size_t http://stackoverflow.com/questions/772531/net-equivalent-of-sizet – DmitryK Aug 24 '09 at 03:25
  • Don't read too much into the "Int" part of "IntPtr." It's a hint, not a promise of an implementation detail. IntPtr handles what you want it to in a bitness-independent fashion. – John Rudy Aug 24 '09 at 03:49
  • I used reflector to look inside the implementation of IntPtr. While it doesn't seem like it is limited to hold and int inside it, all the ToString(), ToInt32() and even ToInt64() will internally first cast the internal value to int, and only after to will cast to string and long respectively. So it seems IntPtr indeed is ONLY to ints, while UIntPtr is indeed to uints! – devoured elysium Aug 24 '09 at 04:26
  • Actually, it's quite strange. Looking at the UIntPtr code that does not happen. I mean, with UIntPtr, when you call ToString(), ToUInt32(), ToUInt64() it will not try to cast first to uint, and only after to string and uint64. – devoured elysium Aug 24 '09 at 04:33

3 Answers3

3

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.

DmitryK
  • 5,542
  • 1
  • 22
  • 32
2

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.

David McEwing
  • 3,320
  • 18
  • 16
  • 1
    AWE doesn't change the memory size. It (address window extension) allows you to map a window inside a 4GB addressable space to something outside (higher than 4GB in physicall RAM) but for the process it will still look inside 4GB. – DmitryK Aug 24 '09 at 03:20
  • So from what I understand I should be using uints. Now, as this is pointer related I'll be using UIntPtr instead of IntPtrs, right? – devoured elysium Aug 24 '09 at 03:22
2

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.

Community
  • 1
  • 1
John Rudy
  • 37,282
  • 14
  • 64
  • 100
  • So that does mean that if I use IntPtr I will be always safe, is that it? – devoured elysium Aug 24 '09 at 03:36
  • "Safe" is a relative term, but `IntPtr` is the *correct* way to approach your design. I'm hesitant to use the word safe as there's generally not much *truly* safe about digging through another process's memory space. :) – John Rudy Aug 24 '09 at 03:47