Address of variable needs to be loaded into memory?

Question

I have an issue - with the following code I am trying to find out what is stored at a certain address and how long my static variable is stored at this specific position. (I read that static variables are stored infinitely and was quite surprised - wanted to test if this was true). The code defines a static variable (its address on my system is 0x1000020c0 - This is probably rather random but was continuously the case)

If I now want to find out what integer value is stored at this address I have to first print out the address with $number, which then gives 0x1000020c0. The recasting/reinterpreting of the address (0x1000020c0) gives 100 only! if the address was printed before or if I use &number in the reinterpreting/recasting.

Can someone explain why this is the case?

int static number = 100;  

//  std::cout << number << std::endl; <- prints 100

//  prints 100 and the address 0x1000020c0 in my case
//  std::cout << number << " " << &number << std::endl;

//  this does not work unless &number is printed previously
//  std::cout << "Value is :  " << *reinterpret_cast<int*>(0x1000020c0) << std::endl;

// this does work and show the correct value (100)
std::cout << "Value is :  " << *reinterpret_cast<int*>(&number) << std::endl;

Answer 1

In any given program, the object might, or might not be stored in the address 0x1000020c0. There are no guarantees either way. The address of the object is decided at compile (or possibly at link) time. A change to the program can change the address.

If you never take the address of the local static object, and never modify it, the compiler may optimize the variable away, so that no memory is used. If the object doesn't exist at all, then it definitely doesn't exist at the memory location 0x1000020c0.

If you use the object in a way that requires the object to exist, it will be in some memory location. Taking the address of the object usually triggers such requirement. This is strikingly similar to observer effect in physics.

If you dereference a pointer which does not point to an object (of appropriate type), the behaviour is undefined.

---

when I print recast/reinterpret the value that is at 0x1000020c0 it prints nothing

As I explained above, the object is not guaranteed to exist at the memory location 0x1000020c0.

even though the object was used since i printed its value via std::cout << number;

Accessing the value of an object doesn't necessarily require the object to exist. The compiler may be able to prove that the value of the object is 100, so it can store that value as a constant and not store static object at all.

Besides, even if the static object did exist, it wouldn't necessarily exist in the address 0x1000020c0, unless you take the address and observe it to be so.

---

As a consequence: Don't ever cast an arbitrary number to a pointer (unless you work on some embedded platform that has hardcoded memory mappings). Seeing that the address of an object in one program is 0x1000020c0, doesn't make 0x1000020c0 non-arbitrary in another program.

Answer 2

1. Assuming specific address of number is not the best idea.
2. In C++, static inside a function body is created at first invocation or when first time C++ program flow encounters the variable. They are never created if never used.
3. If possible, a compiler may choose to optimize the static and replace it with the value.

Answer 3

You're missing one very major statement here - the platform you're running this code on.

A static variable isn't stored "infinitely"; it's stored in that location for the duration of the program execution. If you're running on an embedded platform where your code jumps to main() at power-up, then you don't have anything else which will get in the way. If you're running on any other platform (Windows, Linux or whatever), that location becomes free when the program completes, and is immediately available for anything else to use.

It's possible that if you run your program, it completes, and you run it again, then maybe you'll get the same chunk of memory for your program to run in. In that case you'll get the same addresses for static variables. If something else has asked for a chunk of memory between your first run finishing and the next run starting (e.g. Chrome needed a bit more space for the pictures you were browsing), then your program won't be given the same chunk of memory and the variable won't be in the same place.

It gets more fun for DLLs. The same kind of rules apply, except they apply for the duration of the DLL being loaded instead of for the duration of program execution. A DLL could be loaded on startup and stay loaded all the way through, or it could be loaded and unloaded by applications as needed.

All this means that you're making some very strange assumptions. If you get the address of a static variable in your program, and then your program checks the contents of that address, you'll always get whatever's in that static variable. That's how static variables work. If you run your code twice, you'll be getting the address of the location for that static variable at your next run, as set up by your program when you run it that second time. In between runs of your program, that address is 100% free for anything else to use.

As others have already pointed out, after this you may also be seeing effects of compiler optimisation in the specific behaviour you're asking about. But the reason you're asking about this specific behaviour is that you seem to have misunderstood something fundamental to how static variables work.