3 ms·

Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem,

Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practice https://matu3ba.github.io/articles/optimal_debugging/#practi.... More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I am unaware of solutions. The former works via thread sanitizer, undo thread fuzzing and rr chaos mode, but I am unaware of solutions to test lock- and wait-free code besides trying really hard to create race conditions and comparing expected results to observe the race conditions, which does not cover temporal race conditions not observable at a later point. Your statement like the general "safety" discussion is missing numbers on compilation time vs run time cost and coverage or any form of metrics to estimate risk vs benefit with cut-off values. Specifically input set/formulae coverage for functions and component planning would be interesting to discuss systems at scale (not basic code coverage), but I am unable to get decent information on that.

lolinder 2y ago
> Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true. And if it's not the latter, then it's not a failure of memory safety as most people mean it.
- steveklabnik 2y ago
  There’s stack probes that cause an abort.
bikeshaving 2y ago
My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?
- 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 ago
    I 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.
matu3ba 2y ago
Looks like my definition of memory safety is wrong and it means only "Runtime makes sure incorrect memory reads/writes are not possible", not by what means, so crashing is under that definition ok.

lolinder 2y ago

> Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true. And if it's not the latter, then it's not a failure of memory safety as most people mean it.

steveklabnik 2y ago
There’s stack probes that cause an abort.

bikeshaving 2y ago

My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?

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 ago
  I 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.

matu3ba 2y ago

Looks like my definition of memory safety is wrong and it means only "Runtime makes sure incorrect memory reads/writes are not possible", not by what means, so crashing is under that definition ok.