4 ms·
> Now that memory errors are slowly disappearing, it's integer problems that are becoming the pain-in-the-neck for exploits. Indeed. Progress! :) I think you
by ArkyBeagle 10y ago
> Now that memory errors are slowly disappearing, it's integer problems that are becoming the pain-in-the-neck for exploits.
Indeed. Progress! :)
I think you may be right about Z_{2^32} but 'C' is hopelessly wedded to it. As practice, it might even be worth having separate types for things on that ring and things expected to not be on that ring. Whether tools to automatically check it exist or not, this at least moves it to be easier to inspect for.
- burfog 10y agoRust should have forced you to specify behavior whenever the compiler can't prove that the difference doesn't matter, like so: 1. default - fail the compile if an overflow could happen 2. wrap - like gcc's -fwrapv option, and C's unsigned type 3. trap - like gcc's -ftrapv option 4. saturate - common DSP behavior 5. unsafe - like gcc's C signed integer cruelty (fastest code) Eh, is it too late to add this? For compatibility with old code, there could be a compiler option to override the default behavior for a whole source file.
- the_why_of_y 10y agoYou're right, there does not appear to be a way to achieve 1. Rust arithmetic does 3. in debug builds, or something vaguely similar if requested by using the checked_* functions, and 2. in release builds, or if requested by using the wrapping_* functions, and 4. by using the saturating_* functions. Recommended reading: http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ http://huonw.github.io/blog/2016/04/myths-and-legends-about-...