3 ms·
Rust's safety mechanisms aren't about buffer overflows. But if you can get away with always using a specific vector type throughout the code (instead of using t
by jstimpfle 7y ago
Rust's safety mechanisms aren't about buffer overflows. But
if you can get away with always using a specific vector type throughout the code (instead of using the simpler and more modular rawpointer+length/rawpointer+offset+length scheme), and you enable bounds checking when compiling, then yes, you probably can get there most of the way or even all the way. But it will be more painful in my experience, and there might be a noticeable performance overhead (I've actually never used Rust but many other languages with objects).
- heavenlyblue 7y agoIsn’t Rust Vec a pointer and a length by itself?
- steveklabnik 7y agoA pointer, a length, and a capacity. Slices are pointer and length.
- heavenlyblue 7y agoYeah, you are right - I missed out the capacity part. Why is the parent pointing out Vec as being “opposed to a raw pointer, a length and a capacity”?
- steveklabnik 7y agoI believe that they mean you can’t mess it up; a slice is much nicer than two separate things. There’s no way to get them out of sync, etc.
- jstimpfle 7y agoI was pointing out vector objects (as opposed to rawpointers) mainly because I'm not aware of any other practical way to enable automated bounds checking. Apart from that I actually find it more appealing and "correct" to have a separate length value. As soon as there are multiple parallel arrays the vector approach will have redundant length information, so from an aesthetical point from of view I prefer not to glue the length to the vector/array. But yeah, with a separate length there is more manual work for simple tasks, so it's easier to mess up.
- pjmlp 7y agoBy being part of the same data structure and managed by the compiler there is no way to get out of sync, due to copy-paste or mismatch when several arrays are being used together.