[Bug c++/55767] New: flowing off end of function which returns a value isn't treated as an error by default

[rui.maciel at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55767

             Bug #: 55767
           Summary: flowing off end of function which returns a value
                    isn't treated as an error by default
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rui.maciel@gmail.com


Consider the following code:

<code>
#include <iostream>

int& foo() {}

int main(void)
{
    foo() = 1 + 1;

    std::cout << foo() << std::endl;

    return 0;
}
</code>

Function foo() returns a value, which is a reference to an int, and in spite of
no return statement being provided, g++ compiles the above code without
throwing any error.  It does throw a warning when compiling with -Wall.

In the C++ standard, in section 6.6.3, it is stated that "A return statement
without an expression can be used only in functions that do not return a
value".  It is also stated that "Flowing off the end of a function is
equivalent to a return with no value", following that "this results in
undefined behavior in a value-returning function."

In spite of this behavior being explicitly left in the standard as "undefined
behavior", this loophole contradicts other behavior specifications made by the
standard.  Even then, its definition of "permissible undefined behavior" the
standard also includes "terminating a translation or execution (with the
issuance of a diagnostic message)".

As the example above shows, by ignoring the situation completely without even
issuing any diagnostic message, g++ is opening the doors to results which
aren't easily explained or expected, which constitutes a problem.

I've noticed that clang++ throws a warning by default for this particular
example, and I've read reports that MSVC++ 2010 actually throws a compiler
error, which is the best possible result for this kind of problem.

It would be nice if g++ handled functions that flowed off the end as errors
instead of silently accepting them by default.