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

That list alone sounds like it does not work.


As long as it is possible to produce a OOB in something as simple as a matrix transpose, Rust also does not work: https://rustsec.org/advisories/RUSTSEC-2023-0080.html.


While a package with 10 million all-time downloads is nothing to sneeze at, it's had one memory corruption bug reported in its ~7 year life.

It's being compared to a C library that's held to extremely high standards, yet this year had two integer overflow CVEs and two other memory corruption CVEs.

SQLite is a lot more code, but it's also been around a lot longer.


The point is that matrix transpose should be trivial. But my main point really is that looking at CVEs is just nonsense. In both cases it is is a rather meaningless.


except that if you read into the actual issue you will realize that transposing matrices high performant is surprisingly not trivial, e.g. see this code code: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a...

furthermore the issue at core was an integer overflow, which is tricky in all languages and e.g. has poppet up on HN recently in context of "proven correct" code still having bugs (because the prove didn't use finit precision integers)

it's also less tricky in rust then in C due to no implicit casts and debug build checking for integer overflows and tests normally running against debug builds

Projects do sometimes enable it even on release builds for security sensitive code(1).

so if anything the linked issue is in favor of using rust over C while acting as a reminder that no solution is perfect

(1): It comes at a high performance cost, but sometimes for some things it's an acceptable cost. Also you can change such setting per crate. E.g. at a company I worked at a few years ago we did build some sensitive and iffy but not hot parts always with such checks enabled and some supper hot ML parts always with optimizations enabled even for "debug/test" builds.


Bounds checking for matrices is trivial. The point is that once you compete with C and need to do something slightly more complex, mistakes also can happen in Rust. Now, we can have a discussion if it is still safer and I may even agree), but it defeats the "eliminate a whole class of issues" marketing, doesn't it?


And something as simple as a for loop to iterate over an array of elements with an off-by-one error can cause undefined behavior in C. Let's not pretend that there's some universally-agreed-upon hierarchy of what types of bugs are unconscionable and which ones are unfortunate unavoidable facts of life just because certain ones existed in the older language and others didn't.




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

Search: