what does this mean?

[Michael]

int& mmin(const int &a, const int &b)
{
int c=a+b;
return c;
}

---------------

I got confused... variable c is initialized in the function "mmin". It
should be on the stack. After the function is done, the storage of "c"
should be gone too...

That does the "int &" do as a reference to a non-existing variable?

Suprisingly, it worked with no problem...

Anybody can explain?

 

[Frederick Gotham]

Michael posted:

int& mmin(const int &a, const int &b)

This is a function called "mmin". It returns a reference to a non-const
int. It takes as arguments two references to const int's.

{
int c=a+b;
return c;

Here you return a reference to a local variable -- the local variable will
have been destroyed by the time the calling function gets to use it.

}

---------------

I got confused... variable c is initialized in the function "mmin". It
should be on the stack. After the function is done, the storage of "c"
should be gone too...

Yes you're right, "c" will have been destroyed.

What does the "int &" do as a reference to a non-existing variable?

Suprisingly, it worked with no problem...

Anybody can explain?

The following works on my own system too:

#include <iostream>

int &Func()
{
int i = 7;
return i;
}

int main()
{
std::cout << Func() << '\n';
}

The current International C++ Standard, however, does not define the
behaviour of this program.

The program attempts to access an object which has been destroyed.

 

[Pete Becker]

The following works on my own system too:

It only works most of the time. It will fail if an interrupt comes along
between the time that Func returns and the result is passed to the
stream inserter. That's a very narrow window, which is why you don't see
it happen too often. But if you run the program enough times, it will
eventually fail.

The point being to underscore that not showing visible symptoms is not
the same as working correctly.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[loufoque]

Frederick Gotham wrote :

Here you return a reference to a local variable -- the local variable will
have been destroyed by the time the calling function gets to use it.

Actually, no, it's UB.

 

[Rolf Magnus]

int& mmin(const int &a, const int &b)
{
int c=a+b;
return c;
}

Standard C++ doesn't require a stack. It defines that variable to be an
automatic one.

After the function is done, the storage of "c" should be gone too...

Well, it might or might not. You can't rely on anything here. The behavior
is undefined.

That does the "int &" do as a reference to a non-existing variable?
Yes.

Suprisingly, it worked with no problem...

Anybody can explain?

Undefined behavior means that anything can happen.

 

[Frederick Gotham]

loufoque posted:

Actually, no, it's UB.

You sure about that? As far as I know, the behaviour of the following
program is well-defined:

int &Func()
{
int i; return i;
}

int main()
{
Func();
}

Similarly, I believe the following programming is also well-defined:

int Func() { /* No return statement */ }

int main() { Func(); }

 

[Kai-Uwe Bux]

loufoque posted:



You sure about that? As far as I know, the behaviour of the following
program is well-defined:

int &Func()
{
int i; return i;
}

int main()
{
Func();
}

I don't know about that one. But it looks fishy.

Similarly, I believe the following programming is also well-defined:

int Func() { /* No return statement */ }

int main() { Func(); }

[6.6.3/2]
.... Flowing off the end of a function is equivalent to a return with no
value; this results in undefined behavior in a value-returning function.


Best

Kai-Uwe Bux

 

[Frederick Gotham]

Kai-Uwe Bux posted:

[6.6.3/2]
... Flowing off the end of a function is equivalent to a return with no
value; this results in undefined behavior in a value-returning function.

Out of interest, I think it's legal in C89 so long as you don't try to access
the return value.

 

[Jerry Coffin]

Kai-Uwe Bux posted:

[6.6.3/2]
... Flowing off the end of a function is equivalent to a return with no
value; this results in undefined behavior in a value-returning function.

Out of interest, I think it's legal in C89 so long as you don't try to access
the return value.

That's correct (section 6.6.6.4): "If a return statement without an
expression is executed, and the value of the function call is used by
the caller, the behavior is undefined. Reaching the } that terminates a
function is equivalent to executing a return statement without an
expression."

In C99, however, the rule changes to be like in C++ (section 6.8.6.4/1,
a constraint on the return statement): "A return statement without an
expression shall appear only in a function whose return type is void."

 

[Frederick Gotham]

Jerry Coffin posted:

In C99, however, the rule changes to be like in C++ (section 6.8.6.4/1,
a constraint on the return statement): "A return statement without an
expression shall appear only in a function whose return type is void."

I read that to mean that you can't have:

int Func() { return; }

It doesn't suggest to me that the following is broken:

int Func() {}

 

[Victor Bazarov]

Jerry Coffin posted:



I read that to mean that you can't have:

int Func() { return; }

It doesn't suggest to me that the following is broken:

int Func() {}

Clarification: "broken" most likely means "ill-formed" here.

 

[Frederick Gotham]

Victor Bazarov posted:

Clarification: "broken" most likely means "ill-formed" here.

I use the term, "broken", when I've to pause for more than two seconds to
consider whether it's "undefined behaviour" or "ill-formed"... it's a blanket
term!

 

[Victor Bazarov]

Victor Bazarov posted:



I use the term, "broken", when I've to pause for more than two
seconds to consider whether it's "undefined behaviour" or
"ill-formed"... it's a blanket term!

Trying to pull some wool over our eyes, eh?

V