32 ms·

> any safety checks put into the competing language will have a runtime cost How about all guarantees static analysis brings to data races, memory ownership, e

> any safety checks put into the competing language will have a runtime cost How about all guarantees static analysis brings to data races, memory ownership, etc? No runtime cost. C tools do not bring this.

zik 4y ago
The valgrind suite is a very effective answer to these needs and it's used by most C programmers. Helgrind for data races. Memcheck for memory ownership. Not to mention sophisticated tools for cache profiling, call graph analysis and heap profiling. No, they're not static tools but being dynamic has a host of advantages too.
- woodruffw 4y ago
  Valgrind's memcheck is great for exercising known paths in a program, and determining whether they're likely to contain memory errors. It doesn't help you discover those paths, which is what attackers are doing when they research and then exploit your program. We've known for decades that compiler mitigations, fuzz testing, and dynamic instrumentation are excellent and necessary components of writing more secure C. But they don't secure C programs, because C itself is fundamentally unsafe. > No, they're not static tools but being dynamic has a host of advantages too. Advantages that any compiled binary can enjoy.
josephg 4y ago
Yep. A few years ago I implemented a skip list based rope library in C[1], and after learning rust I eventually ported it over[2]. The rust implementation was much less code than the C version. It generated a bigger assembly but it ran 20% faster or so. (I don't know why it ran faster than the C version - this was before the noalias analysis was turned on in the compiler). Its now about 3x faster than C, thanks to some use of clever layered data structures. I could implement those optimizations in C, but I find rust easier to work with. C has advantages, but performance is a bad reason to choose C over rust. In my experience, the runtime bounds checks it adds are remarkably cheap from a performance perspective. And its more than offset by the extra optimizations the rust compiler can do thanks to the extra knowledge the compiler has about your program. If my experience is anything to go by, naively porting C programs to rust would result in faster code a lot of the time. And I find it easier to optimize rust code compared to C code, thanks to generics and the (excellent) crates ecosystem. If I was optimizing for runtime speed, I'd pick rust over C every time. [1] https://github.com/josephg/librope https://github.com/josephg/librope [2] https://github.com/josephg/jumprope-rs https://github.com/josephg/jumprope-rs

zik 4y ago

The valgrind suite is a very effective answer to these needs and it's used by most C programmers. Helgrind for data races. Memcheck for memory ownership. Not to mention sophisticated tools for cache profiling, call graph analysis and heap profiling. No, they're not static tools but being dynamic has a host of advantages too.

woodruffw 4y ago
Valgrind's memcheck is great for exercising known paths in a program, and determining whether they're likely to contain memory errors. It doesn't help you discover those paths, which is what attackers are doing when they research and then exploit your program. We've known for decades that compiler mitigations, fuzz testing, and dynamic instrumentation are excellent and necessary components of writing more secure C. But they don't secure C programs, because C itself is fundamentally unsafe. > No, they're not static tools but being dynamic has a host of advantages too. Advantages that any compiled binary can enjoy.

josephg 4y ago

Yep. A few years ago I implemented a skip list based rope library in C[1], and after learning rust I eventually ported it over[2]. The rust implementation was much less code than the C version. It generated a bigger assembly but it ran 20% faster or so. (I don't know why it ran faster than the C version - this was before the noalias analysis was turned on in the compiler). Its now about 3x faster than C, thanks to some use of clever layered data structures. I could implement those optimizations in C, but I find rust easier to work with. C has advantages, but performance is a bad reason to choose C over rust. In my experience, the runtime bounds checks it adds are remarkably cheap from a performance perspective. And its more than offset by the extra optimizations the rust compiler can do thanks to the extra knowledge the compiler has about your program. If my experience is anything to go by, naively porting C programs to rust would result in faster code a lot of the time. And I find it easier to optimize rust code compared to C code, thanks to generics and the (excellent) crates ecosystem. If I was optimizing for runtime speed, I'd pick rust over C every time. [1] https://github.com/josephg/librope https://github.com/josephg/librope [2] https://github.com/josephg/jumprope-rs https://github.com/josephg/jumprope-rs