Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Preface: I don't think this behavior is necessarily dangerous, nor am I really sure it needs to be fixed, but wanted to hear others thoughts on it.
I think in an ideal world
Test should be able to detect that there is a bad loop and time out. At which point the code causing the loop will be detected and can be fixed by the programmer.
If we put a limit on the depth it will be too low for some and to large (oom before reaching the limit) for others. An existing case similar to the problem is that fmt Stringer can get into an infinite recursion too.
As I assume a user can not control creating a loop directly through malicious input if the programmer doesnt want it. Being an attack vector for denial of service is the reason some std lib packages put depth limits on processing input. I dont think this applies here.
Ah! Not sure how I missed that during my search. It sounds like there haven't been huge numbers of people hitting this issue since your issue, so documentation is probably not hugely necessary, but it does sound like it could perhaps save someone a headache if they hit this in a hypothetical feature... Either way not opposed to just closing this out if everyone is ambivalent.