2 ms·
> Something as core as proper stack handling is to me basic functionality. rustc handles it just as much as other compilers do. It should be safer than that, b
by Manishearth 11y ago
> Something as core as proper stack handling is to me basic functionality.
rustc handles it just as much as other compilers do. It should be safer than that, but it's currently not due to a compiler bug, and features making it safer are not "basic stack handling".
This is not undefined behavior, as has been said multiple times in this thread; please stop repeating this lie. This is a deterministic crash that can't be exploited easily.
> And, any project which resents such technical / conceptual criticism leaves one with much to ponder.
No, their comment said "inflammatory/unnuanced/ill-informed criticism". Which yours is.
- Annatar 11y ago> This is not undefined behavior, as has been said multiple times in this thread; please stop repeating this lie. I wrote: "and there are undefined behaviors, or in this case such bugs". "Whoever can read is clearly at an advantage". > No, their comment said "inflammatory/unnuanced/ill-informed criticism". Which yours is. I'll tell you what: if I had deployed Rust in production and I ran into crap like the article described, I'd be really pissed.
- Manishearth 11y agoThis "crap" is a stack overflow. The "correct" way of handling this crap is to terminate the process on a stack overflow (Rust does this for most stack overflows anyway). The current incorrect way causes a segfault instead, which also terminates the process -- not much of a difference for a production user; it crashes either way. This can lead to bad memory reads if you try really hard to write code that leads to it, and that too it will happen a small fraction of the time -- all the other times it will segfault-crash (and would be caught in testing or in deployment without being exploited).
- deleted 11y ago[deleted]