3 ms·
Given the example that one side of || is a tail call, it seems quite easy to accidentally have overflows that only occur on specific data and call time environm
by yayana 9y ago
Given the example that one side of || is a tail call, it seems quite easy to accidentally have overflows that only occur on specific data and call time environments for situations like writing a bad binary heap traversal function. Without tail calls, any traversal to some depth either does or doesn't trigger a stack overflow.
But I find the need for step debugging to catch and unroll a virtual equivalent to tail calls a better argument given that this is for a sandbox for adversarial code with strong incentives to obscure bad behavior.
- saurik 9y agoIt is already trivial to break up logic and destroy the stack using async, if for some reason we are to believe that the call stack is somehow a way for us to somehow figure out we are being attacked. (Also, is it really surprising that the right-hand side of a returned || expression is a tail call? That seems extremely obvious :/. Regardless, the "syntactic tail call" proposal seems like it fixes that issue.)
- yayana 9y agoFeatures like async now have a few debugging options that can help users identify origin and report malicious redirects, pop-unders etc that try to obfuscate history and here comes a potential replacement.. So worrying about debugging first isn't such a bad idea. It's extremely obvious to think about tail calls when you know you are supposed to be thinking about tail calls. The life cycle of JS Code doesn't usually make anything obvious to people who inject the last edge conditions in a function.