Please leave recursion to math and keep it out of (in particular C) software: it kills and will kill again.
Kind regards from libexpat, see CVE-2022-25313 and CVE-2024-8176 for proof.
Please leave recursion to math and keep it out of (in particular C) software: it kills and will kill again.
Kind regards from libexpat, see CVE-2022-25313 and CVE-2024-8176 for proof.
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-callsBut 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.
Hmm, I wonder why it’s considered O2 heavy. The concept of turning tail recursion into loops is simple.
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.