tags:

views:

507

answers:

5

Is there a way to print out the lowest and highest memory address that an Operating system can address in c?

+3  A: 

No, this is not a feature of standard C. Whatever solution you need will need to be OS-specific.

If you have some specific OS' in mind, you should mention them. But I'm having a hard time wondering why this would matter. It's not required to be able to write C programs, so perhaps you could enlighten us.

Based on your comment:

What I'm curious is "if each process gets an address space in memory, can I be able to print out the top-address and bottom-address of that process?"

Again this depends on the OS. Your address space is not necessarily the physical memory you have, it's the totality of the locations you can address. For example, an operating system based on x86 may give every single process its own 4G address space but you have to ask the OS for "backing" memory (actual real memory to put in that address space).

And some of that address space is actually shared amongst all processes (where the OS can load one physical copy of its code for the use of all processes, for example).

You have to remember that virtual memory and physical memory are very different beasts.

paxdiablo
thanks, i got it.
tsubasa
+3  A: 

On Linux, you can interrogate the memory map for any running process by looking at /proc/[PID]/maps; see proc(5). For example:

$ cat /proc/self/maps
08048000-0804f000 r-xp 00000000 03:01 63119      /bin/cat
0804f000-08050000 rw-p 00006000 03:01 63119      /bin/cat
08050000-08071000 rw-p 08050000 00:00 0          [heap]
b7c58000-b7e09000 r--p 00000000 03:05 243564     /usr/lib/locale/locale-archive
b7e09000-b7e0a000 rw-p b7e09000 00:00 0
b7e0a000-b7f39000 r-xp 00000000 03:01 63497      /lib/libc-2.7.so
b7f39000-b7f3a000 r--p 0012f000 03:01 63497      /lib/libc-2.7.so
b7f3a000-b7f3c000 rw-p 00130000 03:01 63497      /lib/libc-2.7.so
b7f3c000-b7f40000 rw-p b7f3c000 00:00 0
b7f5b000-b7f5c000 rw-p b7f5b000 00:00 0
b7f5c000-b7f76000 r-xp 00000000 03:01 63276      /lib/ld-2.7.so
b7f76000-b7f78000 rw-p 00019000 03:01 63276      /lib/ld-2.7.so
bfc83000-bfc98000 rw-p bffeb000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]

For this process, the last entry in the memory map is 0xfffff000, so the last addressable byte is 0xfffff000 - 1.

Commodore Jaeger
A: 

On modern operating systems with virtual memory and memory protection, the bounds of a process' address space are not static. When you allocate memory from the heap, that can be implemented by the operating system mapping more physical memory into your address space, thus causing that space to grow.

unwind
A: 

The most important thing here is process memory and OS memory are completely different things. So speaking "in C" do you really mean something different from process memory space?

I suggest this could help, at least give you some direction. Another thing is brk(2) / sbrk(2). These mechanics are not so often used as my experience shows.

Roman Nikitchenko
+3  A: 

The simple answer is that on a 32-bit address system (for example), the address range is [0x00000000, 0xFFFFFFFF]. But that does not mean you can actually access every byte within that range. You need to know how the operating system and compiler arrange the memory within your program, i.e., where the static data segment is, where the heap is, where the stack is, etc.

And realize than on any given program running on a modern operating system, most of the address space is unmapped.

With virtual memory, every process has its own address space, so that the byte at address 0x0010F444 (for example) in one process is a completely different physical byte than the byte at the same address in every other process.

Loadmaster
Also, the heap may not be contiguous, there are memory-mapped files as well as shared library code in your address space. Phew!
Artelius