From: Andrew on
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?".
Further, I note that GCC does not even issue a warning (at least not
with the default warning level).

Surely it is just plain wrong to say that a function returns an int
(say) and then just have 'return' with no value. Doesn't that mean
that effectively the return value will be random. How can this ever be
right?

Regards,

Andrew Marlow

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Ulrich Eckhardt on
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! ]

From: Andrew on
On 27 July, 21:48, A Curious Developer <imdb...(a)yahoo.com> wrote:
> > So my question is, "why is this not a fatal compilation error?".
>
> It might have been done that way so that compilers don't need to do
> code analysis to determine which paths might or might not be taken and
> so the language wouldn't be complicated by rules covering which kinds
> of analysis need to be done.

Maybe, but you don't get a warning from GCC with the code below:

int doNothing()
{
}

There aren't many code paths to analyse in this case ;-)

> Also, some paths that throw exceptions
> might have no reasonable return values. (That is just a guess ... I
> don't necessarily agree it justifies the results.)
>
> I think gcc has an option to give related warnings - -Wreturn-type,
> perhaps.

Yes, with this option you do indeed get the warning. I wonder why it
is not the default.

-Andrew Marlow


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]