4 ms·

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken.

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy. This is annoying in Rust. To me array accesses aren't the most annoying, it's match{} branches that will never been invoked. There is unreachable!() for such situations, and you would hope that: if array_access_out_of_bounds { unreachable!(); } is recognised by the Rust tooling and just ignored. That's effectively the same as SQLite is doing now by not doing the check. But it isn't ignored by the tooling: unreachable!() is reported as a missed line. Then there is the test code coverage including the standard output by default, and you have to use regex's on path names to remove it.

steveklabnik 1y ago
A more direct translation of the sqlite strategy here is to use get_unchecked instead of [], and then you get the same behaviors. Your example does what [] does already, it’s just a more verbose way of writing the same thing. It’s not the same behavior as sqlite.
- rstuart4133 1y ago
  > A more direct translation of the sqlite strategy here is to use get_unchecked instead of [], and then you get the same behaviors. Array access was just an example. My point was that Rust makes 100% code coverage for unit tests well neigh impossible. For those of us who like 100% test coverage, that is a major annoyance. For way I use Rust that could be fixed by the tooling simply not counting unreachable!() lines as unreached. For Sqlite, who does branch coverage testing on the compiled binary you would have to go a step further, and provide a compile time option that elides all paths that lead to unreachable!() from the binary. I recall Sqlite saying when they changed to 100% branch coverage, their bug reports dropped by a factor of 7. I hope I remember that correctly. If I do, I'm pretty sure they won't be looking at Rust until they can achieve the same outcome. They can't come close now. Replacing every array access with get_unchecked() and the consequent explosion of unsafe area's wouldn't fly with anyone I worked with. You did say to me in another thread unsafe is perfectly fine in Rust programs, but you are literally the only person holding that opinion I come across.

steveklabnik 1y ago

A more direct translation of the sqlite strategy here is to use get_unchecked instead of [], and then you get the same behaviors. Your example does what [] does already, it’s just a more verbose way of writing the same thing. It’s not the same behavior as sqlite.

rstuart4133 1y ago
> A more direct translation of the sqlite strategy here is to use get_unchecked instead of [], and then you get the same behaviors. Array access was just an example. My point was that Rust makes 100% code coverage for unit tests well neigh impossible. For those of us who like 100% test coverage, that is a major annoyance. For way I use Rust that could be fixed by the tooling simply not counting unreachable!() lines as unreached. For Sqlite, who does branch coverage testing on the compiled binary you would have to go a step further, and provide a compile time option that elides all paths that lead to unreachable!() from the binary. I recall Sqlite saying when they changed to 100% branch coverage, their bug reports dropped by a factor of 7. I hope I remember that correctly. If I do, I'm pretty sure they won't be looking at Rust until they can achieve the same outcome. They can't come close now. Replacing every array access with get_unchecked() and the consequent explosion of unsafe area's wouldn't fly with anyone I worked with. You did say to me in another thread unsafe is perfectly fine in Rust programs, but you are literally the only person holding that opinion I come across.