Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
I did it the other way around in uni, we got a task with no mention of it requiring recursion (even though I suppose it was somewhat well suited to it). I solved it with a double for loop and the teacher refused to accept my submission.
This was a coding class on Unix thinclients, I'll let you guess how long ago.
edit: thx [email protected] for making the spoiler work :)Answer
3 years
The spoiler syntax is a bit different.
<label>
<body>
For example:
Answer
3 years
An actual compsci professor would know real CPUs don't run arbitrary recursion, right? Nobody could possibly be that siloed.
Could someone expand a little on this statement, or point me toward an applicable resource? How do "real" (modern?) CPUs prevent unwanted recursion? As in, not the compiler or the OS, but the CPU itself? I've been searching for a while now but I haven't found anything that clears this up for me.
They don't prevent it, they just don't implement it. A real (physical) CPU is a fixed electrical circuit and can't just divide in two the way it would have to for the ideal mathematical version of recursion. If you want a simple way to visualise this, how would you implement recursion (as opposed to just loops) on a Turing machine with tapes?
Different CPUs might have strategies to approximate certain kinds of recursion, but at some point my own knowledge ends, and there has been many different designs. Tail recursion in particular is usually just turned back into a loop at the compiler, and typical modern architectures implement a call stack at the hardware level, which allows you to do limited-depth recursion, but breaks like in OP if you try to go too deep.
Tail recursion in particular is usually just turned back into a loop at the compiler, and typical modern architectures implement a call stack at the hardware level, which allows you to do limited-depth recursion, but breaks like in OP if you try to go too deep.
Yes, in my experience this is what the term "recursion" means in a programming context; it doesn't usually refer to a mathematical ideal. That was what tripped me up.
The basic definition would be something like use of a function in that function's own code. It's pretty easy to find examples that aren't tail-recursive specifically, like mergesort, and examples within those that would overflow a hardware stack, like in OP. And that's without looking at (mildly) exotic examples like the Ackermann function.
Basically, the "Please leave recursion to math and keep it out of (in particular C) software" in OP means don't define functions using those functions. It's pretty and it can work, but not reliably.
...what is your point? Some software (in a language that doesn't have tail-recursion optimization) used recursion to handle user-provided input, and indeed it broke. Someone wrote to explain that that's a potential vulnerability, the author agreed, and fixed it. Who here is misunderstanding how computers implement recursion?
I was answering a specific question put directly to me. There's no "point", exactly.
Who here is misunderstanding how computers implement recursion?
Taking a wild stab at how you might be reading this exchange, my original reply was about the title of the post, which implies a CompSci professor would be unhappy about someone criticising the use of recursion in code.
(in a language that doesn’t have tail-recursion optimization)
Wait, it doesn't? I had kind of assumed GCC (for example) would do that at anything greater than -O0.
Okay, yeah, I was indeed reading your original reply as a criticism of one of the people involved (presumably the security researcher), rather than as a criticism of the post title. Sorry for misunderstanding.
Apparently GCC does indeed do tail-call optimization at -O2: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-foptimize-sibling-calls
But in that case, I'm not sure why the solution to the denial of service vulnerability isn't just "compile with -foptimize-sibling-calls."
I mean, "criticism" is a little extreme even, because it's a humour post, and I was just riffing back.
Apparently GCC does indeed do tail-call optimization at -O2
Hmm, I wonder why it's considered O2 heavy. The concept of turning tail recursion into loops is simple.
But in that case, I’m not sure why the solution to the denial of service vulnerability isn’t just “compile with -foptimize-sibling-calls.”
Probably because some of the recursion involved is non-tail. Actually, it looks like GCC might still be able to cases of corecursion where the functions are "stack compatibale", but presumably most functions aren't, and who knows what little knots they tied the parsing functions in this XML library into.
I think generally C compilers prefer to keep the stack intact for debugging and such.
Yes, definitely. Rereading the StackOverflow, "stack compatible" just means it can mutate the stack frame in place without resizing it in the optimised code. There's a number of ways trying to handle tail (co)recursion sucks if you try and get around that. Here's a Dr. Dobbs about it.