C++ dangling reference strange behaviour

the exam answer was that the function was returning a dangling reference

Correct.

but (...) does not present any undefined behaviour of the program.

What makes you think so? Undefined behaviour doesn't mean "program doesn't work correctly" or "program crashes". Undefined behaviour means exactly what it says: the behaviour is not defined by the standard. In fact it may work "correctly" (whatever that means), the standard doesn't prohibit it. That's why it is so dangerous. Because maybe in your test it works correctly, because of the hardware, OS, specific compiler, some other assumptions that take place. But the problem is that it is not guaranteed to work correctly. If you change machine, OS, a compiler (even switch optimization settings), a code slightly or even compile it two days later it may behave weirdly, in an (ekhm) undefined way.

In general there is no way to know whether a program behaves correctly or not, if UB is present. You are trying to analyze the situation by thinking about l-values, r-values, allocations, etc. while the reality is that when UB is present the entire program is meaningless. You just waste time.

Do not write UB code. Regardless of whether it seems that it works or not.

does not present any undefined behaviour of the program.

Undefined behavior means that there is NO guarantee on the program behavior. The program always seemingly working is allowed under this condition. But it is also allowed that the next time you compile the program with a new compiler version (or even just run the same program again), it may suddenly not work anymore.

In your program both f and crashaFisso return a dangling reference to type int*. That by itself is not undefined behavior. You are allowed to return dangling references and pointers. However, such return values are useless, because they can not be used in any practical way.

In your code

&f(i,u)

is the first problem. You are taking here the address of the dangling reference. This most likely already undefined behavior by itself, I am not completely sure at the moment. If it is not, passing the resulting invalid pointer value to a function outputting the value has at best implementation-defined behavior, which may be ok.

The line

 int* aux = f(i,u);

is definitively undefined behavior. You are trying to take the value from the object that the dangling reference referenced before it was destroyed to initialize the new int* pointer. That is absolutely undefined behavior.

Undefined behavior means anything¹ can happen including but not limited to the program giving your expected output. But never rely(or make conclusions based) on the output of a program that has undefined behavior.

So the output that you're seeing is a result of undefined behavior. And as i said don't rely on the output of a program that has UB.

So the first step to make the program correct would be to remove UB. Then and only then you can start reasoning about the output of the program.

^{1For a more technically accurate definition of undefined behavior see this where it is mentioned that: there are no restrictions on the behavior of the program.}

Your test is not as sharp as it could be: In order to show that the reference is dangling you should actually store the reference and not a copy of the value of the deceased object it refers to.

To understand why that would be more interesting let's dissect the function for a sec.

• int** z = &y; makes z point to y; *z is now an alias for y.
• *z=x; makes a copy of the address value the pointer referenced by x contains and assigns it to the entity known as y or *z. That address is entirely valid (f() is called with the address of main's a).
• return *z; returns an lvalue reference (that is, a reference you could syntactically assign to) to the lvalue *z aka y. That lvalue is of type pointer to int and contains the valid address of main's a. The issue with the code is that what is referred to, namely y, is destroyed as soon as the function has returned so that reading the value through it in cout<<"indirizzo funzione: "<<&f(i,u) is undefined behavior, and the compiler warns about it.

The reason that the program doesn't crash is that immediately after f returns, the memory of its former local variables is still intact. Of course it's illegal to access it, but if you look at the memory it's all there. Consequently, int* aux = f(i,u); simply reads the (valid) address stored in the recently deceased y and stores it as a copy in aux. You can now write on the stack as much as you like: aux will contain a valid value.

That's why you were not successful in your attempts to write on the stack in order to overwrite it.

If instead you store the returned reference to *z aka y you'll refer to the deceased object itself which inevitably will be overwritten by future stack operations or used in other ways by the compiler.

Here is an anglicized, minimal example using a reference instead of a copy (note the definition of the variable dangling_ref). I compile and run it it twice, with standard optimization and with maximum optimization. Simply changing the compiler options changes the output (and, what I'd assume is a bug, determines whether the warning is output!). Here is a sample session on msys2.

$ cat dangling-ref.cpp
#include <iostream>
using namespace std;

int*& dangling_ref_ret(int*& x, int* y)
{
    int** z = &y;
    *z = x;
    cout << "ret addr " << *z << " (should be == " << y << ")" << ", val = " << **z << endl;
    return *z;
}

int main()
{
    int b = 1;
    int* pb = &b;
    int c = 2;
    int*& dangling_ref = dangling_ref_ret(pb, &c);
    cout << "val of dangling_ref " << dangling_ref << " is " << *dangling_ref << endl;
}

$ gcc --version
gcc (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -Wall -o dangling-ref dangling-ref.cpp && ./dangling-ref.exe
ret addr 0xffffcc34 (should be == 0xffffcc34), val = 1
val of dangling_ref 0xffffcc34 is 1
$ g++ -Wall -O3 -o dangling-ref dangling-ref.cpp && ./dangling-ref.exe
dangling-ref.cpp: In function ‘int*& dangling_ref_ret(int*&, int*)’:
dangling-ref.cpp:9:13: warning: function may return address of local variable [-Wreturn-local-addr]
    9 |     return *z;
      |             ^
dangling-ref.cpp:4:38: note: declared here
    4 | int*& dangling_ref_ret(int*& x, int* y)
      |                                 ~~~~~^
ret addr 0xffffcc10 (should be == 0xffffcc10), val = 1
val of dangling_ref 0xffffcc14 is 2

Visual Studio also behaves differently between Debug and Release mode.

You can try different compilers and options on godbolt.

Bruh, it can't never crash because the reference is a variable in the stack and is not out of scope when you exit the function, so it's not deallocated, therefore is not dangling.