4 ms·

It is better, definitely safer. But it's not perfect. I write rust on a daily basis. I've written a lot of C++ in the past. It's safer, but I have memory safety

by eloff 5y ago

It is better, definitely safer. But it's not perfect. I write rust on a daily basis. I've written a lot of C++ in the past. It's safer, but I have memory safety issues in both. It's more a matter of degree. For a large existing code base that are well written I think it's easier to improve the safety of the existing code than rewrite it completely in a safer language.

tptacek 5y ago
People talk about having memory safety issues in Rust and Go, and my general reaction is that these claims tend to be pretty artificial (for instance: they've managed to introduce concurrency bugs that abort their program). If you've got a war story about a security-relevant memory corruption vulnerability you managed to introduce into a Rust codebase (that wasn't in straight-up `unsafe` code), I'd be interested in hearing more about it. My position right now, before hearing that war story, is that Rust vs. C is more than a difference of degree. It's a difference of degree in security writ large, to be sure. But for memory corruption? I'd say the distinction is close to categorical.
- pjmlp 5y ago
  It was already like that in the Pascal/Modula/Ada vs C days. Just because it isn't 100% bullet prof, just 95% better, the C team always advocates it isn't worth the effort.
- eloff 5y ago
  > If you've got a war story about a security-relevant memory corruption vulnerability you managed to introduce into a Rust codebase (that wasn't in straight-up `unsafe` code), I'd be interested in hearing more about it. No, they're in unsafe code. Except Go where you don't get memory safety with some kinds of race conditions. I'm debugging a segfault in Rust today as it turns out. I guarantee it's in unsafe code. But I have some unsafe code. A database would also definitely have quite a bit of unsafe code. It's a lot better than the situation in C. But rewrites always introduce bugs. And sqlite is so well written and tested, it's not a low quality code base. I don't think a rewrite makes sense here, it'd be better to improve the existing code to make it safer. That's my opinion anyway.

by eloff 5y ago

tptacek 5y ago

People talk about having memory safety issues in Rust and Go, and my general reaction is that these claims tend to be pretty artificial (for instance: they've managed to introduce concurrency bugs that abort their program). If you've got a war story about a security-relevant memory corruption vulnerability you managed to introduce into a Rust codebase (that wasn't in straight-up `unsafe` code), I'd be interested in hearing more about it. My position right now, before hearing that war story, is that Rust vs. C is more than a difference of degree. It's a difference of degree in security writ large, to be sure. But for memory corruption? I'd say the distinction is close to categorical.

pjmlp 5y ago
It was already like that in the Pascal/Modula/Ada vs C days. Just because it isn't 100% bullet prof, just 95% better, the C team always advocates it isn't worth the effort.
eloff 5y ago
> If you've got a war story about a security-relevant memory corruption vulnerability you managed to introduce into a Rust codebase (that wasn't in straight-up `unsafe` code), I'd be interested in hearing more about it. No, they're in unsafe code. Except Go where you don't get memory safety with some kinds of race conditions. I'm debugging a segfault in Rust today as it turns out. I guarantee it's in unsafe code. But I have some unsafe code. A database would also definitely have quite a bit of unsafe code. It's a lot better than the situation in C. But rewrites always introduce bugs. And sqlite is so well written and tested, it's not a low quality code base. I don't think a rewrite makes sense here, it'd be better to improve the existing code to make it safer. That's my opinion anyway.