1
#include <iostream>
using namespace std;
int screw(int x){
    if(x==1) 
       return x;
    else 
       screw(x-1);
}
int main(){
    cout<<screw(5)<< endl; 
    return 0;
}

Output of this code: 1 Can anyone explain how the screw(5), screw(4), screw(3), screw(2) are returning 1 when there is no return statement in "else" part of their code. Use of call stack to explain would be highly appreciated. Any insights about basics related to it are very much welcomed.

nerd21
  • 127
  • 1
  • 2
  • 11
  • First, [turn on your warnings](http://coliru.stacked-crooked.com/a/04a54985e0894838). That's your first hint something's wrong. – chris Feb 22 '17 at 04:08
  • 1
    Else path doesn't propagate the returned value. UB as the final return value is lost. – doug Feb 22 '17 at 04:10
  • I didnt get any warning while executing this code. – nerd21 Feb 22 '17 at 04:10
  • 1
    http://coliru.stacked-crooked.com/a/ae495cf71b154f33 – tkausl Feb 22 '17 at 04:11
  • @nerd21, *while executing*? C++ will probably never give runtime warnings. It does give warnings during compilation. – Incomputable Feb 22 '17 at 04:11
  • Just wanted to know how what is being returned, if returned, by else then. And how? Can anyone give insights. It would be of great help. – nerd21 Feb 22 '17 at 04:11
  • 1
    Seems like a problem that could be easily solved with your debugger. – MrEricSir Feb 22 '17 at 04:12
  • I was just wondering if there is only one and thats the last function calls which has return values. What exactly is happening in the other calls which were made prior to it. – nerd21 Feb 22 '17 at 04:15
  • Also see http://stackoverflow.com/questions/9936011/if-a-function-returns-no-value-with-a-valid-return-type-is-it-okay-to-for-the. It's unrelated to recursion. – chris Feb 22 '17 at 04:23
  • No matter the (positive) value of `x` you pass in, the `x` will eventually become `1`. Hence the return value of `1`. –  Feb 22 '17 at 04:34
  • @tkausl *I was just wondering the way how it is being executed inspite of that warning of control reaching to the end. If there is only one and thats the last function calls which has return values. What exactly is happening in the other calls which were made prior to it. – nerd21 Feb 22 '17 at 04:34
  • @RawN but ideally x should be returned only for last call. All the previous calls has no "return statement" because only else part is executed for them. – nerd21 Feb 22 '17 at 04:36
  • @nerd21 I think there is an implicit return after the last statement. –  Feb 22 '17 at 04:38
  • @chris thanks that link helped. Still I havent got the concept crystal clear. But I will try to comprehend those answers with various perspectives. – nerd21 Feb 22 '17 at 04:44
  • @RawN even if we assume so, how the value that has to be returned will be decided? – nerd21 Feb 22 '17 at 04:44
  • @nerd21, As far as C++ goes, this is undefined behaviour. The compiler is free to do anything it wants. You shouldn't rely on anything. – chris Feb 22 '17 at 06:11

1 Answers1

1

In C/C++ calling convention on x86 architecture, funtion returns value in eax register. The 'return val' statement in C updates eax with val. If there's no explicit 'return val', the value happens to be in eax register becomes the function return value. In you example, the innermost call puts 1 in eax when it returns, which is propogated to all recursive calls.

cyb70289
  • 77
  • 7
  • Thanks a lot. Beautifully explained. It cleared my doubt. But can you make reference for your answer just for the sake of authentication or I can some have some solid ground to back my answer in future, wherever I make the same point. – nerd21 Feb 22 '17 at 04:51
  • @nerd21, Note that this is not guaranteed, even on x86. For example, consider this: https://godbolt.org/g/XnbIVR. Here, the compiler is able to realize that the else branch contains undefined behaviour. Therefore, the else branch cannot legally be executed. Therefore, the compiler can remove it completely. – chris Feb 22 '17 at 06:15
  • Just as chris said, it depends on compiler, optimization, architecture, etc, the final assembly code is not guaranteed. – cyb70289 Feb 22 '17 at 13:47
  • @chris oh I got your point. And reading assembly code for same helped to realize that EAX register thing. Thanks:) – nerd21 Feb 22 '17 at 16:01