Address of Pointer is fixed in every execution

In my program address of pointers is fixed in every execution.
for example:
pointer A is "0x624f40" in every execution.
I did not find any reason for this.

Thanks for nay help or guidance
It's the way memory is handled in modern operating systems.

programs 'think' they own all the memory - and in something like windows - programs think they
have 4GB (in 32bit terms) of memory to play with.

So when you write a program and the compiler says something like "I will put this variable at address 0x624f40"
So when you run the program, it will display 0x624f40 for the address of that variable.
If you run a thousand copies of the program at the same time they will all say the same address - that was how the program was compiled.

However, these thousand variables are actually located at completely different acdresses in the physical memory of the computer - because the operating system and the CPU maps the virtual addresses of the program
to different memory pages of the physical RAM (the OS keep a list of Descriptor tables and memory address are translated between program addresses and real RAM addresses as required)

So in summary - the addresses displayed by the program is not the actual physical RAM address of the variable

If you want a proper indepth explanation then I suggest you read
a books on systems programming and on how CPUs like the Pentium works.

It is all good stuff;
Last edited on
As they are no other replies or corrections - I assume you all either agree or disagree with what I said?
You're pretty much right, guestgulkan. The compiler will say more like "I will put this variable at address .data + 0x0f40", and the program loader (OS component) will position .data at the virtual memory address 0x624000. Addresses where the different program sections are placed are typically the same every time (unless the OS changes, the program is recompiled and changes size, etc)

Examples of program layouts:
~$ pmap $$
884:    bash -l
00010000     640K r-x--  /usr/bin/bash
000B0000       8K r-x--  /usr/bin/bash
000C0000      64K rwx--  /usr/bin/bash
000D0000      16K rwx--  /usr/bin/bash
000D4000     288K rwx--    [ heap ]
FFBF0000      64K rw---    [ stack ]

here code occupies addresses 0x10000 .. 0xBffff, data occupies 0xC0000 .. 0xd3fff, heap grows up from d4000 and stack grows down from the top. If this bash creates a pointer to the first static object and prints it, it's likely going to be always 0xc0000.

Another OS:

$ cat /proc/30844/maps
00400000-004b2000 r-xp 00000000 fd:00 98410                              /bin/bash
006b2000-006bc000 rwxp 000b2000 fd:00 98410                              /bin/bash
006bc000-006c1000 rwxp 006bc000 00:00 0 
008bb000-008c3000 rwxp 000bb000 fd:00 98410                              /bin/bash
0fd1b000-0fd7c000 rwxp 0fd1b000 00:00 0                                  [heap]
7fffbda43000-7fffbda58000 rw-p 7ffffffe9000 00:00 0                      [stack]

Here program data begins at 0x6b2000, which is more like what the OP has
Last edited on
AFAIK you explained it pretty well. When compiled, the computer only knows memory locations. The variable names are strictly for human convenience. The only exception to this rule, I think, would be objects created on the heap (dynamically). Since at compile time it isn't known what objects and how many will need to be created, they get a place at run time.
Programs get loaded at the same base address, mostly. And that causes you to get deterministic/repeatable addresses unless there's some asynchronous or external interfering event.

That's why GCC programs can be compiled with -pie to make them relocateable, to make them less deterministic.
Last edited on
Topic archived. No new replies allowed.