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.
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)
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.
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.