3 ms·

There was a similar bug in the past in Rust: Integer overflow causing a buffer overflow: https://github.com/rust-lang/rust/pull/54399/commits/8ac88d375e00c91a3d

by uecker 3y ago

There was a similar bug in the past in Rust: Integer overflow causing a buffer overflow: https://github.com/rust-lang/rust/pull/54399/commits/8ac88d375e00c91a3db5d78852048322f88be3c1 https://github.com/rust-lang/rust/pull/54399/commits/8ac88d3... So the answer is: Not necessarily. I agree though that the memory safety features in Rust would help reduce the risk. On the other hand, one could also write safer C by abstracting away buffer management. The world is not black and white.

e44858 3y ago
That function was using an unsafe block to disable the bounds check. This kind of bug would likely be impossible in "safe" rust (that didn't use unsafe).
- ajross 3y ago
  The linked glibc code was likewise being fancy trying to use a stack buffer to avoid a heap allocation. Idiomatic C would have worked just fine too. The point is that Rust is also (though not as severely) subject to developers playing tricks and hurting themselves.
- uecker 3y ago
  In reality people use unsafe to optimize and then introduce bugs. You could also use a safe abstractions to avoid bounds violations in C.
  - zamalek 3y ago
    That isn't the use-case for unsafe. If you see a codebase doing this then you should stop paying attention to or using that codebase. Unsafe is for creating things that are beyond the understanding of the borrow checker. For example, using unsafe is mandatory for creating a mutex because the safety rules are upheld by the data structure itself. Unsafe is not "C mode" as most would assume - it is more unsafe than C because if you don't uphold the memory model things will break. Rust's strict aliasing and mutability rules provide ample opportunity for compiler optimizations and zero cost abstractions. Turning to unsafe is generally a sign of incompetence/arrogance.
bobbylarrybobby 3y ago
The amount of lines added, let alone unsafe lines, is really startling for such a conceptually simple operation.

by uecker 3y ago

e44858 3y ago

That function was using an unsafe block to disable the bounds check. This kind of bug would likely be impossible in "safe" rust (that didn't use unsafe).

ajross 3y ago
The linked glibc code was likewise being fancy trying to use a stack buffer to avoid a heap allocation. Idiomatic C would have worked just fine too. The point is that Rust is also (though not as severely) subject to developers playing tricks and hurting themselves.
uecker 3y ago
In reality people use unsafe to optimize and then introduce bugs. You could also use a safe abstractions to avoid bounds violations in C.
- zamalek 3y ago
  That isn't the use-case for unsafe. If you see a codebase doing this then you should stop paying attention to or using that codebase. Unsafe is for creating things that are beyond the understanding of the borrow checker. For example, using unsafe is mandatory for creating a mutex because the safety rules are upheld by the data structure itself. Unsafe is not "C mode" as most would assume - it is more unsafe than C because if you don't uphold the memory model things will break. Rust's strict aliasing and mutability rules provide ample opportunity for compiler optimizations and zero cost abstractions. Turning to unsafe is generally a sign of incompetence/arrogance.

bobbylarrybobby 3y ago

The amount of lines added, let alone unsafe lines, is really startling for such a conceptually simple operation.