errors: As can loop endlessly #40589
Comments
|
I don't think the stdlib should be placing arbitrary limits on unwrapping errors |
|
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. |
ALTree
added
the
NeedsDecision
|
This is a dup of #34957, where I closed it saying
|
|
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. |
|
I'll close this as a duplicate of #34957, but please feel free to continue discussion there, or let me know if I am mistaken. |
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.
errors.Ascan enter an infinite loop if the error chain it is unwrapping contains a loop (here is an incredibly obvious example, the same thing would happen ifloopErrself-referenced). While my example is quite obviously a "user did something silly" issue, the longer and more complex an error chain becomes the higher the likelihood something like this could happen and causeerrors.Asto sit in a tight loop when the caller tries to unwind it. Sinceerrors.Asisn't using recursion it won't cause a stack overflow and the only indication of an issue will be that the program appears to just halt.I think in an ideal world
errors.Aswould prevent this from happening. Obviously doing full on loop detection is a bit overkill for a relatively simple stdlib function, but adding a panic when the innerforloop exceeds some maximum number of iterations (i.e. 1000, likely to be significantly larger than any real world error chain) would at least let the user know there is something bad happening.The text was updated successfully, but these errors were encountered: