Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's the job of the compiler to optimize out things it knows are secure. If an array lookup is known to be secure at compile time, then LLVM already optimizes out bounds checking without the need of a fast mode [1].

If there is not enough evidence available to the compiler that a particular array lookup is not safe, then that evidence is also not available to the programmer. Therefore, one would have to write a manual bounds check anyway. Double bounds checking, one by the compiler and one by the compiler, can also be optimized out.

Maybe Rust is not capable of completely covering all optimization cases right now, but I don't think there's a need for a turn-off-all-checks mode.

Does anybody have any material about how a turn-off-all-checks-mode improved performance for another language? I'm curious about what the difference is.

[1]: https://github.com/rust-lang/rust/issues/9024



> If there is not enough evidence available to the compiler that a particular array lookup is not safe, then that evidence is also not available to the programmer.

That's quite wrong. Humans are capable of deductions that compilers, which must necessarily use conservative, constructive methods, can't dream of. They can also have information that isn't available to a compiler even in principle, although this is less likely to apply to eliminating bounds checking.


Yes, and programmers on a development team change with time, taking their knowledge with them.

So the next guy touching the code just makes the code blow up, due to wrong assumptions.


It's worded quite strongly, but the programmer can only be certain that a certain bounds check is guaranteed to succeed if the compiler agrees. In other situations something about the current context may allow a bounds check to pass, but the "current context" is always bound to change in any sufficiently complicated program.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: