I don't want to claim that the compiler wouldn't optimize my snippet in the crude manner that you implied; however my snippet is not "in question." I was demonstrating my answer: That statics are stored in the same place as globals with access restrictions. My snippet was more of a test to see if you could globally poke at the value of something static. Had you not been able to, the assertion should have failed, (like it would for a pointer to a local automatic variable).But back to the point in question, I don't think the variable is question is a variable, I think it
just tells the compiler that that function returns an integer, thats all, nothing more. [...] it would only exist temporilary on the stack when the function had been called and
was returning it's return value, so it is really a dynamic variable.
What you later stated is a possibility, but static variables cannot be destroyed at any point in run time (as dynamic ones can). As I stated, statics could be copied around from the function stack like you said. But the lifetime of the static variable is well defined, unlike a dynamic one: as long as from the point of initialization to the termination of your program. There's no need to explicitly manage static memory, and although implementors may opt to do that behind the scenes, I don't think that is the case for many. Personally, I wouldn't do it that way.
OP: c will live just as I described but it may point to other places in memory that make c invalid.