Perhaps a better question would be, Why do you expect it to be different?
The only possible thing I can think of is that you're assuming the address
is absolute across the entire memory of your computer -- it isn't. It's
relative to the address space of your program.
So if you run the program once, it may load into the 100th page of RAM,
and if you run it again, it may load into the 150th page of RAM. But the
address of the variable *relative to the starting address of your program*
will always be the same.
I personally own a system with a multitasking multiuser Unix-like OS
on which your claims about addresses are exactly backwards.
On that particular system, addresses as visible to C programs *are*
absolute addresses acrosss the entire memory of the computer, and
the addresses of static variables are chosen at run-time by the
loader, so the address of variables relative to the starting
address of the program are -not- always be the same.
C has had a long history of running on systems with relocating
loaders and which used Position Independant Code (PIC) as much as
possible, with the loader doing address "fixups" as needed.
One of the two major branches of Unix (I -think- it was BSD) went
the route of giving consistent virtual address spaces to programs,
but the other (System V) did not. The major non-trivial work in
porting a game such as NetHack used to be in the save and restore
routines -- with the BSD version blithely writing out memory
*including pointers* to save files, but the SysV version having to
carefully convert all the pointers into cursors upon save, and
build the cursors back into pointers upon load.
If you look at the C89 and C99 standards, the only portable way
to write out a pointer is using a %p format, which is only documented
as producing *some* representation of the pointer, not one that
necessarily has anything to do with any internal address space.
C99 promises that if you use %p to read back in such a pointer
in the same program, that the resulting pointer will compare equal
to the original pointer, but my memory (sorry, don't have
my reference material here) is that C89 does not make that promise
about being able to read back in %p. If the run-time care to go through
the bother, it could write out a %p as something like "<pointer #7>"
as long as it kept track of what #7 corresponded to in memory.
Printing out a pointer as a numeric value involves a system-
dependant conversion from pointer to numeric value; implementations
need not define any useful meaning for such a conversion.
You can take the tactic of taking the address of the beginning
of a pointer, coercing that address to unsigned char *, and
printing out sizeof(*whatever) bytes as numeric values, but
pointers need not be simple variables: the visible value
of a pointer can be (for example) the address of a memory descriptor
that gives information about types and bounds and actual memory
address of the data. (This was the case for a major vendor for awhile.)
