3 ms·

> C debuggers and tooling are vastly more powerful than Rust's static type system, and catch a much wider array of memory problems (, and bugs) than the Rust co

> C debuggers and tooling are vastly more powerful than Rust's static type system, and catch a much wider array of memory problems (, and bugs) than the Rust compiler can catch. Static verification is far more limited than the dynamic verification a sophisticated debugger can perform. Is there any dynamic verifier that fully validates all acesses w.r.t. the object trees specified by the C standard? Tools like ASan and UBSan won't detect a write to one field running into another field, only a write overrunning the complete object. (Compiler-level hardening might catch that to some extent, but it's limited to TU boundaries.) Not to mention things like 'misuse of restrict pointers' that I've never seen any verifiers for, except for special cases like overlapping memcpy() buffers. Meanwhile, Rust does have its own dynamic verifier, called Miri [0], which checks just about every language-level rule at runtime. The main drawbacks are that it's slow and doesn't support calling arbitrary C functions, but it would be hard to get that to work short of the Valgrind route of emulating the whole process on an instruction level. [0] https://github.com/rust-lang/miri https://github.com/rust-lang/miri

mjburgess 2y ago
If you're redoing the c std, which was my initial point, you can introduce a debug allocator with metadata about object layout. Coupled with some debugger support, i'd imagine you can get there. And if the C std was willing to allow constexpr to do more at compile time, you wouldn't need explicit debugger support and could just use constexpr to modify the compiler. There's also nothing stopping debuggers reifying the C at debug-time into this metadata. My claim is 95% can be fixed by just normalizing what is current practice at the stdlib level and compiler level. By extending constexpr, i think you could get to 100%. Given that this is the case, why even both with the nightmare of Rust.
- LegionMammal978 2y ago
  Oh, you sounded like you were talking about something that already exists today, rather than something that you'd like to exist. The main problem with taking dynamic verification all the way is making it work with ABI boundaries, which won't be going anywhere in at least the next decade. You'd need everyone to migrate to a universal ABI that can convey all needed metadata, and while I've seen a few proposals for that, none of them have gone anywhere.
  - mjburgess 2y ago
    I was more saying that the scope of issues mainstream tooling catches, includes ones that the rust compiler doesn't catch, and many more than enough for what are common memory safety issues -- there are some issues that aren't caught, sure -- but the operations which can cause those bugs are well-defined, most programs wouldnt have to use them, and a new std lib would help. When people propagandize about C, they're universally unaware that the normal process of development basically addresses most of the problems Rust is supposed to be solving, and more than the rust compiler alone solves. The remainder are 95% to do with libc, which should just be thrown out. A smidge more compile-time eval with constexpr, and the use case for Rust could disappear. It's a great shame that C is run by a standards process that's determined to relegate it to electric motors and digital watches from the 80s.

mjburgess 2y ago

If you're redoing the c std, which was my initial point, you can introduce a debug allocator with metadata about object layout. Coupled with some debugger support, i'd imagine you can get there. And if the C std was willing to allow constexpr to do more at compile time, you wouldn't need explicit debugger support and could just use constexpr to modify the compiler. There's also nothing stopping debuggers reifying the C at debug-time into this metadata. My claim is 95% can be fixed by just normalizing what is current practice at the stdlib level and compiler level. By extending constexpr, i think you could get to 100%. Given that this is the case, why even both with the nightmare of Rust.

LegionMammal978 2y ago
Oh, you sounded like you were talking about something that already exists today, rather than something that you'd like to exist. The main problem with taking dynamic verification all the way is making it work with ABI boundaries, which won't be going anywhere in at least the next decade. You'd need everyone to migrate to a universal ABI that can convey all needed metadata, and while I've seen a few proposals for that, none of them have gone anywhere.
- mjburgess 2y ago
  I was more saying that the scope of issues mainstream tooling catches, includes ones that the rust compiler doesn't catch, and many more than enough for what are common memory safety issues -- there are some issues that aren't caught, sure -- but the operations which can cause those bugs are well-defined, most programs wouldnt have to use them, and a new std lib would help. When people propagandize about C, they're universally unaware that the normal process of development basically addresses most of the problems Rust is supposed to be solving, and more than the rust compiler alone solves. The remainder are 95% to do with libc, which should just be thrown out. A smidge more compile-time eval with constexpr, and the use case for Rust could disappear. It's a great shame that C is run by a standards process that's determined to relegate it to electric motors and digital watches from the 80s.