> It is silly to make an overly broad statement about recursion killing. On modern "hosted" OSes, there are safeguards about stack overflows, which will quickly kill your process.

Something doesn't make sense here.

>> denial of service was considered to be the realistic impact

is in the article as justification for why this has low criticality and therefore isn't subject to the 90 day disclosure timeline. I.e. it's _limiting_ the predicted impact.

I assumed GP was referring to the other more critical risk, stack clashing, which I guess could lead to RCE? not being an issue on modern OS's.

This doesn't make sense as a comment, regardless of the the particular conclusion.

There are lots of contexts where a processing being killed is bad.

Sending a deeply nested JSON object as part of a request to some API should not crash the server that handles the request.

In contexts where availability matters, recursing on user supplied input is dangerous.

  int recursive_fun(rec_context *ctx, ...)
  {
    int res = 0;
    if (++ctx->depth > REC_LIMIT)
       return ERROR_RECURSION_LIMIT;
    ...
       res = recursive_fun(ctx, ...);

    out:
      ctx->depth--;
      return res;
  }

If recursion traverses an exponentially sized abstract space, it can chew up a lot of processing time before going anywhere near the protective limit.

Many "fixes" for recursion effectively re-implement it, but do so with their own data structures that are equivalent to the stack (as originally used) but have precise definitions and therefore can be controlled wrt resources used.

If the OS provides ample stack space, you can inquire about the limit, and subtract a safety margin from that to create your own soft limit that you can test against in the recursion.

Another way is to be absolutely restrictive, rather than track the limit. Create some test cases representing the worst recursive cases you're willing to handle (and document as such). Empirically measure their stack use. Multiply that by 1.5 and use that as the stack check limit.

On startup you can check that this soft limit is not too close to the real one and diagnose the situation.

If your soft limit is many megabytes away from the real one, you're not likely to hit the real one, unless something really stupid happens, like alloca, or a call into some code you don't control that goes rampant.

The submitted article, by the way, could use more nuance like this. Careless recursion in C, without reasoning about the consequences (what happens for certain inputs) is obviously bad, not recursion itself.

    > Careless recursion in C... is obviously bad

    > Another way is to be absolutely restrictive, rather than track the limit. Create some test cases representing the worst recursive cases you're willing to handle (and document as such). Empirically measure their stack use. Multiply that by 1.5 and use that as the stack check limit.

Doing it all in your VM/runtime, so you can bail the computation with an exception, is more challenging.

Is forking a new process on each call to a recursive function practical?

But the API should have limits. For example, respond 413 Payload Too Large if the request is beyond any normal size for that API. Document the limits to API users. You now have an upper bound of how much nesting can be in the user input.

In the general case though, recursion can be tricky to think through, the stack is small, and malicious inputs can be very creative.

Table-driven LALR(1) with an explicit stack does not make the recursion issue go away. The tooling may provide built-in handling for it which translates excessive depth into a syntax error.

Recursive parsing using the native stack can take steps to protect itself, like by keeping track of the depth, and bailing upon hitting a limit.

Techniques involving obtaining the stack pointer (or close estimate thereof), and comparing it to a limit, are also possible.