Why does my C++ program crash when I forget the return statement, rather than just returning garbage?

Question

I've started using CLang recently to compile embedded C++ ARM programs.

Prior to this I used GCC and C, almost exclusively for embedded work.

I've noticed that when I have a method that returns a value, and I forget the return statement, the program core dumps. There is no error printed other than "msleep error -1" from one of my device drivers. This is on FreeBSD.

I would expect that forgetting the return statement would just result in garbage being returned from the function, not a core dump.

EDIT: I'm returning a bool, not a pointer or object or anything complicated. The program crashes even when the return value doesn't matter.

What is going on?

E.G.:

bool MyClass::DummyFunc() {
  <do some stuff and forget the return value>     
}

Elsewhere:

if(pMyObj->DummyFunc()) {
  print ("Hey, it's true!\n");
} else {
  print ("Darn, it's false!\n");
}

That code should not crash, regardless of the return value.

Answer 1

From second hand sources because I don't want to pay for the C++ standard, it apparently says:

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.

This is C++, when you do something undefined you should expect it to crash your computer and eat your laundry, unless the implementation says otherwise.

Answer 2

I would expect that forgetting the return statement would just result in garbage being returned from the function, not a core dump.

What is going on?

Your expectation is wrong, is what's going on.

The compiler — an incredibly complicated piece of machinery — is free to assume that your function returns a value, because you promised that it did.

Then you broke that promise.

This is why we shall not make assumptions about implementation details, particularly when writing programs whose behaviour is undefined. You cannot make a direct comparison between C++ code and "some data goes into this register and there is this call stack that does precisely this thing".

There are near-infinite ways that this can break, because in the process of converting your C++ code to a well-optimised program readable by your computer, the compiler makes a series of extremely complicated optimisations, and any one of them can be snapped in half by your violation of the standard's rules. Attempting to determine exactly what happened on any particular run of your program would require the following knowledge:

• CPU make, model and version
• operating system make, model and version
• compiler make, model and version
• all compiler flags
• 10 years' experience with the compiler's source code
• time machine to inspect the state of every bit of memory in your computer at the time of your program's execution.

It's really just not worth it.

Fortunately, in certain cases, we can additionally rationalise about this case without betraying the abstraction: for example, consider what happens when you promised you'd return a std::string, but didn't, and then that non-existent std::string goes out of scope. The destructor is being invoked on random nonsense, and that's not going to go well.

Answer 3

Forgetting the return value results in the control flow reaching the end of a function. The C and C++ standards both describe this case. Note that main is an exception to this case and is described separately.

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 C++11 Draft pg 136

My experience with clang has been that the compiler will treat instances of "undefined behavior" as will not happen and optimize away the paths. Which is legal, since the behavior is undefined. Often clang will instead emit an illegal instruction along the omitted path so that the code will crash if the "impossible" happens, which is likely your case here. In fact, the compiler could then determine that calling DummyFunc() results in undefined behavior and therefore cannot happen, and instead start optimizing away the calling bodies.

gcc is far "friendlier" and tries to generate something nice, such as returning 0.

Note, both compilers are correct and are producing valid code according to the standard.