Gcc 4.8.3 does not spot missing 'return' keyword

Question

Let's look at such piece of code:

#include <iostream>

int foo(int i) {return i; }

int foobar(int z) {return foo(z);}

int main() {
std::cout << foobar(3) << std::endl;
}

It compiles fine with g++ -std=c++11 ... and gives output 3. But The same output is given by:

#include <iostream>

int foo(int i) {return i; }

int foobar(int z) { foo(z);}

int main() {
std::cout << foobar(3) << std::endl;
}

It compiles without problems but clearly the keyword return is missed in foobar. Is it a bug in gcc 4.8.3 or maybe I'm not aware of some c++11 principle? (Runned on Fedora 20)

Answer 1

The code compiles fine because it is well-formed, and so you can run it. But since this is undefined behavior, you cannot rely on any behavior of the program, anything is legal. To prevent accidents like this, enable compiler warnings. if you compile your code with -Wall, you will see

main.cpp:10:28: warning: no return statement in function returning non-void [-Wreturn-type]
 int foobar(int z) { foo(z);}

Here you can get more information about those warnings. Use them and make sure your code compiles warning free. It can catch a lot of errors in your code at compile time.

Answer 2

The C++ standard doesn't make a mandate for compilers to insist on a return-statement in functions return non-void. Instead, flowing off the end of such a function without a return-statement is undefined behavior. The relevant statement in the standard is in 6.6.3 [stmt.return] paragraph 2, last sentence (and in 3.6.1 [basic.start.main] paragraph 5 is the statement making it OK for main() to flow off this function):

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.

The primary reason for this approach is that it may be non-trivial or even impossible if the function actually ever really returns. Consider this function declaration and function definition:

extern void will_always_throw();
int does_not_return_anything() {
    will_always_throw();
}

Assuming will_always_throw() indeed does as the name suggests, there is nothing wrong. In fact, if the compiler gets smarter and manages to verify that will_always_throw(), indeed, always throws (or a "noreturn" attribute is attached to will_always_throw(), it may warn about the last statement in this definition never being reached:

int does_return_something_just_in_case() {
    will_always_throw();
    return 17;
}

The general approach to deal with these situations is for compilers to support suitable options enabling/disabling warnings as necessary. For example, on your code all compilers I have access to (gcc, clang, and icc) create a warning assuming warnings are enable (using -Wall for the first two and -w2 for Intel's compiler).