#include <iostream>
int fn(int num)
{
if(num > 5)
return 7;
}
int main()
{
std::cout << fn(3) << "\n";
return 0;
}
C++ - When not all paths lead to a return?
Author
I was curious, so I compiled the following program and ran it in VS 2003:
In debug mode it printed a random 5 digit negative number and in release mode it printed a random 5 digit positive number.
I was surprised this even compiled, I thought that I would get an error message saying "not all paths lead to a return" or something. Yet, it does and spits out weird things. Does anyone know if this is even supposed to compile? Or is VS 2003 just being weird?
When I do that sort of thing I get a warning, but it still compiles and does the random return value thing. Don't ask me what the official answer is though.
Correct me if I'm wrong, but I believe by convention the return value is stored in the eax register on x86 architectures, and so omitting a return statement will cause the function to essentially return whatever happens to be in eax. Since it's used for all types of calculations, you're bound to get strange things returned.
well if you call the function and the variable passed in is not less then 5 then you are just outputing some random value...whatever the system happens to want to return as an integer for your function call. It will always be a random chode value, just whatever is in memory at that time unless the number you pass in is greater then 5. It will compile but it will output random nothingness values.
This is a common problem. A neat way to solve this is to add this in your header files:
#pragma warning( error : 4715 )
Now whenever your paths may possibly not return a value, you will get an error instead of an easy-to-miss warning. You really don't want to let one of those slip by as they can be very tricky to debug.
Personally I think this should always be an error, even by default.
#pragma warning( error : 4715 )
Now whenever your paths may possibly not return a value, you will get an error instead of an easy-to-miss warning. You really don't want to let one of those slip by as they can be very tricky to debug.
Personally I think this should always be an error, even by default.
OK, this is really some weird results
my VS 2003 behaves in the same way, BUT only for C++. I tried similar code in C#, and the compile failed with "not all code paths return a value" error. Considering the compilers were written with the same inner rules, it seems that it's a correct C++ snippet. It's actually logical and correct, in such a piece of code
enum Answer {Yes,No};
bool func(Answer a)
{
switch(a)
{
case Yes:return true;break;
case No:return false;break;
}
}
Adding an additional return statement in the end of the function is not natural and senseless. So, C++ just gives you the choice to add the return in the endc when you need it
my VS 2003 behaves in the same way, BUT only for C++. I tried similar code in C#, and the compile failed with "not all code paths return a value" error. Considering the compilers were written with the same inner rules, it seems that it's a correct C++ snippet. It's actually logical and correct, in such a piece of code
enum Answer {Yes,No};
bool func(Answer a)
{
switch(a)
{
case Yes:return true;break;
case No:return false;break;
}
}
Adding an additional return statement in the end of the function is not natural and senseless. So, C++ just gives you the choice to add the return in the endc when you need it
Quote:Original post by Sheeva_
OK, this is really some weird results
my VS 2003 behaves in the same way, BUT only for C++. I tried similar code in C#, and the compile failed with "not all code paths return a value" error. Considering the compilers were written with the same inner rules, it seems that it's a correct C++ snippet. It's actually logical and correct, in such a piece of code
Nope. In either language you can cast an arbitrary integer value to the enum type and sneak another value in.
Author
mutex: Your explanation for the random values sounds reasonable [smile].
ScootA: Neat trick. I haven't been bitten by this yet, but chances are I will sometime in the future. [grin]
Does anyone know whether having the possibility that the function does not return a value is allowed in the C++ standard or not? Or is this another one of those undefined behavior things? It seems kinda weird to allow this sort of thing to happen.
ScootA: Neat trick. I haven't been bitten by this yet, but chances are I will sometime in the future. [grin]
Does anyone know whether having the possibility that the function does not return a value is allowed in the C++ standard or not? Or is this another one of those undefined behavior things? It seems kinda weird to allow this sort of thing to happen.
You are lucky compilers add a return statement at the end of functions at all. Otherwise your code would continue to execute whatever code follows that function.
I don't know what the C/C++ standard on this is, but just imagine what might have happened if the compiler didn't return at all [grin]
I don't know what the C/C++ standard on this is, but just imagine what might have happened if the compiler didn't return at all [grin]
It shouldn't be, and here's the reason: when you return a random int, it's usually not really dangerous. But when the function returns something that contains pointers, and the pointers are random, this leads to totally weird results, like data corruption. Even with the int case, if the function is supposed to return an array index, the bug could be quite hard to spot out without boundschecking. And there are lots of other errors with random return values. A random bool will be true in almost all of the cases, for instance. It's not so obvious that it is random as an integer.
So every such function is a potential bug, even if you're sure it never happens (because you're never 100% sure). I would consider this as an error if I developed the standard :)
So every such function is a potential bug, even if you're sure it never happens (because you're never 100% sure). I would consider this as an error if I developed the standard :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
