Re: why are missing return statements from non-void functions not a compilation error
Andrew wrote:
In the process of cleaning up some legacy C++ code I have been
eliminating various compiler warnings I am getting from Visual Studio.
One of them, C4715, is "not all control paths return a value". Sure
enough, the function in question has a return type of int, and there
are various embedded returns but no final return at the end, a control
path that it can get to.
So my question is, "why is this not a fatal compilation error?".
There are other ways to leave a function that don't involve return. The
compiler may not be able to detect if such a way is involved in the code.
Examples:
- throwing an exception
- terminating (abort(), exit())
- unreachable code
Further, I note that GCC does not even issue a warning (at least not
with the default warning level).
GCC issues pretty much no warnings at all by default. Any sane programmer
uses -W... therefore.
Surely it is just plain wrong to say that a function returns an int
(say) and then just have 'return' with no value.
Actually, that _is_ a case that will be flagged by the compiler, but that is
something different than falling off the end of a function.
Doesn't that mean that effectively the return value will be random.
How can this ever be right?
Falling off the end of a non-void function causes "undefined behaviour".
That means that the C++ standard doesn't make any requirement on the
behaviour.
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]