There's a useful clang-tidy function to warn on this, for when you want to ensure there is no recursion lurking anywhere in a large codebase sensitive to stack overflow issues:
https://clang.llvm.org/extra/clang-tidy/checks/misc/no-recur...
https://clang.llvm.org/extra/clang-tidy/checks/misc/no-recur...
And if you're writing your own language, you can just have explicit 'colored' functions (and corresponding pointers), and enforce that the call graph between different colors has no cycles, and no function invokes a pointer of its own color. Generics would get a bit messy, but it's still far from impossible.
if(fptr == x || fptr == y)
__builtin_unreachable()
if(fptr != z && fptr != w)
__builtin_unreachable()
enum { CALL_Z, CALL_W };
int call_z_or_w(int which, int arg) {
switch (which) {
case CALL_Z: return z(arg);
case CALL_W: return w(arg);
default: __builtin_unreachable();
}
}
Sure, in toy examples. But you can't actually do this in a nontrivial codebase that wasn't written to support it from the ground up.
> And if you're writing your own language, you can just have explicit 'colored' functions (and corresponding pointers), and enforce that the call graph between different colors has no cycles, and no function invokes a pointer of its own color. Generics would get a bit messy, but it's still far from impossible.
Everything is easy when you don't spend 5 minutes thinking about the possible problems with it, much less actually implement the idea you're proposing.
> But you can't actually do this in a nontrivial codebase that wasn't written to support it from the ground up.
In the case where this is considered critical for whatever reason, you absolutely could have a somewhat overzealous detector that failed the compilation if triggered. It doesn't need to support every last edge case. You would then address this just as you would any other compiler error - by remediating the failures one by one.
If management doesn't want to pay you to do that then perhaps the requirement of "absolutely no recursion ever" wasn't actually so critical.
From an architectural standpoint, the main challenge is layering everything properly so you don't have any circular dependencies, even in untaken branches. Again, how hard this is to achieve depends on the original design, but it's not like circular-dependency-avoidance is something that no one's done before.
That's still overly optimistic when you're talking about something that no-one's ever done.
> You would then address this just as you would any other compiler error - by remediating the failures one by one.
And what do you do in the meantime? Or when you can't see how to fix one of the cases? When a new feature introduces an error, you don't push out the new feature until you can fix the error, possibly never. When a compiler upgrade introduces an error all over your codebase (that you can't fix with something like a one-liner regex), you turn it off (in the best case you turn it into a warning that you then maybe gradually fix), and if you can't turn it off you don't do the compiler upgrade.