3 ms·
Trusting the fuzzer and not examining its coverage seem to be main problem here. I fail to see what is problematic about giving the control over the entire flo
by artariel 4y ago
Trusting the fuzzer and not examining its coverage seem to be main problem here.
I fail to see what is problematic about giving the control over the entire flow of the program to the developer. Quite the contrary, I am more concerned about the paradigm shift towards higher level system programming languages that hide more and more control from the developer while putting more burden on the perfectness of optimizer.
- alkonaut 4y agoAbsent a high performing systems language that still offers some safety guarantees, the right call should be to use whatever the second best is. It could be a higher level language with runtime overhead, sandboxing, formal verification etc. In some cases constraints won’t allow this, and obviously replacing even parts of infrastructure code is never easy. Nor should the perfect be the enemy of the good - adding better testing doesn’t sound like a bad idea even for a piece of code being sunset. What I’m objecting against is the (apparent, or my perceived!) idea that “if only the fuzzing was good enough, this code would be acceptable for use forever.
- saagarjha 4y agoThe average developer is typically more error prone than their compilers is.