Search:

Thanks John , kindly why it's like this? I didn't get how my recursive function is equivalent to what you suggested .. could you illustrate please how it's same as my recursive function?

first recursive solution


int divide(int a)
{
if (a > 1) {
return divide (a/2);
}
return a;
}

I understand but I already wrote the code for loop solution and recursive solution above , so then what next step shall I do for proving what you're suggesting that recursive call counts same as for...

thanks much , some inline comments as you see below.

> There's no function call overhead.
when you say function overhead what do you mean exactly could you elaborate please meaning of function...

I understand , thanks.



like what Im trying to understand why we need to avoid generally recursion .. any reason aside to stackover flow case?? there is also another reason which is related to...

why if (a>1) then you return 1? my original function is return divide(a/2) ;

Hi ,
I totally understand the recursion in C programming and now trying more further to understand what is going behind the scenes , so trying please to have the conversion on assembly language for...

I got it , thank you all.

I got you so I can say it's same address returned because we call the "same function" at "same line of code" and this only leads to that same address is returned , otherwise would be different .. ,...

Got you totally , you meant different places in terms of stack frames positions.

second concern , the code itself is executed by CPU and not by operating system , so when we say main function...

totally you convinced me, one point here regard to your statement " stored in different places " .. what do you mean by different places? could you elaborate more ..

I understand point 2 (second queston).

regard to first question answer , Yes I understand that there's a __start function which is kind of c library environment and the value of the main is...

Hi ,
Im trying to understand very deeply what's going with stack frame in terms of stack param storing once calling the function , even more complex on recursion case.

As understand once we call...

I understand , thanks much for your cooperation.

What do you mean?

offset is actually the size of data type " unsigned int r = 0 " , but why offset goes away? I understand that we are doing subtraction ..

kindly , can you please give an example with some address...

Got you , it's a tricky way you are trying to do.

like lets say main function its stack frame for instance 0x0 - 0x8 (assumption) now you are saying that getting address of r will like give us 0x9...

Not getting you exactly , how this gives you the current stack address? like on assembler version it uses esp register where it points to current stack address ..

thanks much actually I found something on internet which is really good , its simple solution for detecting stackoverflow within given size before stackover flow happens.

see here please :


...

When we run a compiler is actually telling us that there is stackover flow so this I know :) , but challenge is to code some thing and same purpose manually and on trivial way for stackover flow...

First off thanks much for your effort , I understand .
but again I think what Im asking is more simply than what you're trying to asnwer.

assume it's given that you have int stackmemory[100]...

this is good thing thanks for forwarding , too much things there to read which exactly function to read there?

I understand , thanks.
Assume that you given this challenge how you would tackle it? .. can we on C programming do like okay we already know we have only 100 bytes (stackmemory 100) so what about...

Thanks much for your response and feedback, all what you're saying make sense and I consent with. but again this is the challenge or the problem is to tackle what I asked for which is to keep track /...

Hi ,
I studied recursion on c programming and I have one concern about stack memory handling on recursive calls while recursive function is getting executed. specifically how things are done on...