-3

I made a mistake when I made a recursion function whose purpose is get a largest fibonacci value in Integer32 in c++.

The mistake I made was

int get_largest_in_fibonacci(int before, int current){
    if(current < 0){
        return before;
    }else{
        get_largest_in_fibonacci(current, before + current);
        // should have been 
        // return get_largest_in_fibonacci(current, before + current);
    }
}

I didn't return in the else statement.

But In this question that's not I want to know.

int main(){
    cout << "result : " << get_largest_in_fibonacci(1,1) << '\n';
    return 0;
}

In this main(), The result was result : 2 . But I can't understand where does 2 come from.

Because, That badly behaving function can't return a value.

At first, I thought the argument (1,1) would have been able to 2 in somewhere.

So I changed their value like (3,5) but the result was same.

And then I thought maybe that could be a garbage value.

But I think garbage value almost always keep giving me random "big" number, but that was not the case in here.

And after I changed the main() little bit like this.

int main(){
    int result = get_largest_in_fibonacci(1,1);
    cout << "result : " << result << '\n';
    return 0;
}

Just assigned the function result to int result.

But In this time, the result was result : 0 .

So I wonder how did the get_largest_in_fibonacci returned in the first place, and how does return value changed by just assigning it to int variable?

codeDog
  • 33
  • 5
  • 2
    Does this answer your question? [Why does flowing off the end of a non-void function without returning a value not produce a compiler error?](https://stackoverflow.com/questions/1610030/why-does-flowing-off-the-end-of-a-non-void-function-without-returning-a-value-no) – Retired Ninja Jun 27 '23 at 11:12
  • 1
    "Garbage" is not random or large or strange, it's just something that nobody wants but is still lying around somewhere. Just like your real-world garbage isn't necessarily unusable or broken or rotten. – molbdnilo Jun 27 '23 at 11:16
  • "But I think garbage value almost always keep giving me random "big" number, but that was not the case in here." thats a misunderstanding and the reason "garbage number" is my favorite dislike. When your code is wrong then even `0` or `1` can be "garbage". And the actual problem with wrong output is when you cannot distinguish it from the right. Else there would be no issue in the first place – 463035818_is_not_an_ai Jun 27 '23 at 11:16
  • 3
    It's undefined behaviour so anything can happen however in a lot of implementations returned value is stored in a register, if you omit the `return` the function ends without setting the register so you'll get whatever was last stored in the register as your result. Presumably some part of your code is setting that register to `2`. Remember that computers are deterministic, they don't behave randomly, your "garbage value" has to come from somewhere, it could be 0, 1, 2 or any other value all of which would be equally wrong, you might even find that your code happens to work correctly – Alan Birtles Jun 27 '23 at 11:23
  • https://en.cppreference.com/w/cpp/language/ub – Jesper Juhl Jun 27 '23 at 11:48
  • You try to reason out various possibilities, but the truth is something different. When you write a bugged program like above (bugged because of the missing return) almost always it means your program has *undefined behaviour*. That is the truth, C++ does not define **any behaviour at all** for your program. So if you want to explain your programs actual behaviour it has nothing to do with the C++ language, instead you should be thinking about your compiler. What does it do when given bugged code? It can do anything it likes and still call itself a C++ compiler. – john Jun 27 '23 at 11:52
  • 2
    Note that your approach is fundamentally flawed regardless of the missing return; signed integer overflow has undefined behaviour in itself so you can't rely on "wraparound" to detect it. – molbdnilo Jun 27 '23 at 12:01

1 Answers1

3

Your assumption is wrong. A function not returning type void that fails to return in an execution path exhibits undefined behaviour if that path is taken during runtime. At that point all bets are off. The program may crash, return 2 or anything else or delete your home folder.

gcc by default emits a warning, that should be heeded, as all warnings should:

warning: control reaches end of non-void function [-Wreturn-type]

bitmask
  • 32,434
  • 14
  • 99
  • 159