Thread: reference operator following return type?

Originally Posted by pantherse

should have printed "1", which is the value of x that was passed to func() but it didn't. What happened is that the execution of func() completed and returned the memory address that "a" used to occupy. However, before the value was printed your kernel decided that it'll put your program on hold, and let another process run. For whatever reason, the kernel gave the memory address that func() returned to that process who wrote something else in the same location. So instead of you getting 1 in your output you got whatever that value was.

That's not true (not for modern operating systems anyway).
Why? Because Virtual Memory separates memory for each process. That means the kernel CAN'T give away the memory location in your program to some other program. The other program writes somewhere else.

Originally Posted by pantherse

Elysia, you are correct. However, it is still possible for a Virtual Memory location to be in one physical location one second, and be relocated by the OS the next. I can get back to you once I get home if you want more details. I don't have my OS theory book on me.

Sure, that happens all the time, but the application itself still can't give that memory to any other application (unless it is asking the OS nicely to share it between the two apps).

Also, if the OS swaps the physical location of the memory, it's the OS's responsibility to make sure that the page being swapped is not being used at the exact moment it is being replaced. So the contents of a memory page should (assuming the OS is bug-free) always be consistent with what the application can expect. So if a value is written to a particular memory location, and the physical memory is being relocated or some such, the same value should be found in the same virtual location after the relocation is done. This is of course tricky stuff, and doing such operations require good understanding of what the machine does, and understanding what processes are able to access such a page, and ensuring that any process that may be accessing that memory is blocked (not running), or things will go (very horribly) wrong in a hurry.

So whether the memory is being "moved" or not, it should have it's content valid whenever the memory is available (if it's not immediately available, the application will cause a page-fault, and the PF handler will block the process, fix up the page so it has it's valid content before making the process runnable again).

--
Mats

A local variable lives on the stack. It is unlikely (although not ENTIRELY impossible) that the OS will deallocate the stack - in which case you would get a page-fault for it being unavailable when it's returned from the function - and if the OS decided that the stack is no longer neede there [unless the stack is grown in an official way, such as calling a function again], then the application would just crash. I do not know of any OS that deallocates the stack after it has shrunk - it will swap it out to disk after it has been out of use for some time, but not deallocate it.

The more likely scenario is that the same area of stack is used by another function, which overwrites the location returned by func(), and the stack content is now something completely different - so the value of "the reference to a" will change at random[1], possibly many times if you call different functions (or the same function with different values). That is because the memory location on the stack that held a whilst in the function, gets re-used for whatever purpose the code wants to use it for when you call those other functions - and that may change if you compile the code with a different compiler or even different compiler switches.

[1] Not random like a random number generator, but random in relation to what you may expect by just looking at the function itself if you didn't realize it was returning a reference to a local variable that will go out of scope.

--
Mats

A likely scenario might be:

Code:

int* foo()
{
    int x = 0;
    return &x;
}

int main()
{
    int* x = foo();
    cout << *x << endl; // It's likely the value is still intact here.
}

However, when we take the following:

Code:

int* foo()
{
    int x = 0;
    return &x;
}

int main()
{
    int* x = foo();
    int y = 1000;
    cout << *x << endl; // You'll probably see 1000 here, instead of 0.
    cout << y << endl;
}

We see that "y" overwrites the data stored in the local variable x inside foo.
This is not guaranteed and should not be relied upon in any sort of way.