3 ms·
If you have the data set of known bugs, going through them should give you the cause. I do expect a strong correlation of basic coverage for simple UB things an
by matu3ba 2y ago
If you have the data set of known bugs, going through them should give you the cause.
I do expect a strong correlation of basic coverage for simple UB things and input set/formulae coverage for the harder to hit ones, specifically as the code scales.
For formal proofs the effort scales quadratically, does Rust code also become quadratically slower with some constant factor?
I'd assume runtime-checks could provide statistical safety and each component may need statistics tweaking unless being small enough/verified/edge cases enumerable with reasonable certainty etc.
Are you aware of any known statistics or work besides the 0,x bugs per 1000 lines of code taking into account classes of bugs?
Or what is your take on this?
- bikeshaving 2y agoI haven’t gone so far as to create a dataset, but you can use GitHub search to quickly peruse the top open source Zig repositories: https://github.com/search?q=+language%3AZig+stars%3A%3E1000&type=repositories https://github.com/search?q=+language%3AZig+stars%3A%3E1000&.... All of them, with the notable exception of tigerbeetle, a financial transactions database, have issue trackers which are littered with users reporting segfaults. I don’t really know if it’s more common than in popular Rust repositories, but this is my highly anecdotal, qualitative investigation. What worries me is that when you dig into specific issues for root causes, there seem to be a lot of different root causes and not a lot of obvious fixes. And segfaults are just the tip of the iceberg, the most obvious memory errors. I don’t think people are reporting heap corruption in the same way, if ever.