Thread: stack overflow

Is there no other viable solution?

the thing is, you can design pretty much anything such that you don't need to be recursive. The reason you are overflowing the stack is you are probably making recursive calls an "infinite" number of times. Usually if your code is doing something practical it will never get that deep into the call stack. Ask yourself if you can better solve this with some sort of looping. That's the best I can do with no code. the algorithm is unknown to us.

Fill & Prelude,
I'm a little confused. You both (and others) say recursion is very undesireable. I was looking at my K&R C Programming Language book and on page 186, appendix A, titled under "primary expressions", it says "Recursive calls to any function are permitted.". Why does this contradict what actually seems to work? I'm not a complete idiot but I kinda feel like one right now. I developed this program from a Fortran program that had numerous goto's . To keep as much of the original program in it's previous structure I chose to use function calls instead of goto's...maybe a bad decision. I would appreciate your thoughts...or anyone else's!
Prince

> Recursive calls to any function are permitted
But that doesn't mean that using them is free of any performance issues, or that they can be used in a care-free manner.

I suggest you look carefully at your code to see if any of that recursion is actually a while loop in disguise (actually, all instances of recursion are disguised loops).

For example, both these functions copy stdin to stdout, but one of them has inappropriate use of recursion, and will eventually crash.

Code:

void good ( void ) {
    char buff[BUFSIZ];
    while ( fgets(buff,BUFSIZ,stdin) != NULL ) {
        fputs( buff, stdout );
    }
}

void bad ( void ) {
    char buff[BUFSIZ];
    if ( fgets(buff, BUFSIZ, stdin) != NULL ) {
        fputs( buff, stdout );
        bad();
    }
}

> I developed this program from a Fortran program that had numerous goto's .
This was probably the first mistake - literal translation from one programming language to another is not a good idea considering the poor structure of the starting point.

Personally, I'd carefully document what the program does already (if such a document doesn't exist), then set about designing and implementing the program from scratch. Not only does this give you the opportunity to ditch features you no longer need, its also a better foundation for adding new requirements.

Or perhaps this if you're after a quick fix

Thanks Salem. Do you think instead of the function calls I can possibly use case statements instead to avoid the stack overflow problem?

that would certainly help the stack problem, but it might make your functions rather long.

Not that this is a problem for the compiler, it just makes it more difficult to maintain the code.

In the first place, you should flowchart your program. If it looks too sloppy, or you recurse too many times, you need to either:

a) redesign your algorithm, or
b) increase your stack size (compiler option).

No matter what else, you should flowchart your code. This is a trivial problem, and can't be that difficult. It would certainly help you see flow issues and let you make changes/reorganizations.

It would help to know _what_ you're trying to do-- perhaps there are better algorithms out there.

Sayeh, thanks for your reply. The object of the exercise was to do a direct translation from fortran to c. flowcharting is great if there is time and or budget. beleive me flowcharting is not a common practice at all in industry...only in academia. the fortran application was a very bad design from the getgo and I was told to leave the design as close to original as possible. unfortunately I am not priviledged to paste the code here...I was only looking for ideas from the experts on this board or from those who have had similar experiences.
Prince

There is a goto in C That would have been closer to the original! I'm not suggesting that by any stretch of the imagination but its certainly possible. In fact it might be a really nice way of making the transition. then when its working you can restructure it. Just a thought.

Fill, I had considered it but the thought of goto's wasn't appealing at all. They are bad enough in Fortran and an insult to the C language. I do appreciate your input.

flowcharting is great if there is time and or budget. beleive me flowcharting is not a common practice at all in industry

Flow Charting saves time and money. 80% design, 20% implementation. Only foolish management fails to understand this. You cannot build a house with a complete plan.

I understand-- it is _no longer_ a common practice in industry. That's is precisely why so much abject garbage is turned out now, by amateurs who don't insist on _doing it correctly_.

I wish you the best with your endeavor.

Damn my stubborn fingers-- here is a correction to my previous post:

"You cannot build a house WITHOUT a complete plan."

flowcharting is great if there is time and or budget. beleive me flowcharting is not a common practice at all in industry

It's mandatory where I work. Charting the process saves both time and money. The documentation that results helps people in your situation understand the code you must translate.