Why Safety Profiles Failed

Post by dwattttt » Fri, Oct 25, 2024, 10:17 AM UTC

o11c wrote: post #46

steveklabnik wrote: post #28

Earlier quoted context omitted.

The borrow checker works irrespective of the heap. Memory safety involves all pointers, not just ones that own a heap allocation.

If we're trying to minimize annotation while maximizing C compatibility, it will be necessary to heap-allocate stack frames. This cost can be mitigated with annotations, once again. In this case, a global "forbid leaks even if unused" flag would cover it. Static allocations only need full heap compatibility if `dlclose` isn't a nop. And TLS is the forgotten step-child, but at the lowest level it's ultimately just imp…

Post by badmintonbaseba » Fri, Oct 25, 2024, 10:31 AM UTC

o11c wrote: post #91

tsimionescu wrote: post #59

Earlier quoted context omitted.

How would this fix memory safety issues like std::sort(vec1.begin(), vec2.end()) (where vec1 and vec2 are different vectors, of course)? Or strlen(malloc(100))?

With a safe runtime, a pointer is really something like a `struct { u32 allocation_base, allocation_offset;}`. (it may be worth doing fancy variable-bit-width math to allow many small allocations but only a few large ones; it's also likely worth it to have a dedicated "leaf" section of memory that is intended not to contain any pointers) An implementation of `sort` would start with: `assert (begin.allocation_base ==…

  struct S {
    int arr1[100];
    std::string s;
    int arr2[100];
  };

  void foo(S& s) {
    //arr1 and arr2 are in the same complete object
    //so they are in the same allocation
    std::sort(std::begin(arr1), std::end(arr2));
  }

Post by fmbb » Fri, Oct 25, 2024, 10:41 AM UTC

ameliaquining wrote: post #42

SubjectToChange wrote: post #10

At this point I'm wondering if the purpose of safety profiles is simply to serve as a distraction. In other words, safety profiles are just something people can point to when the topic of memory safety comes up, that’s it. The objectives of the initiative always seemed hopelessly optimistic, if not absurd. In particular, I don't understand why littering a codebase with auto, const, constexpr, inline, [[nodiscard]], n…

I think maybe it's because lifetime annotations can get arbitrarily complicated. If you look at enough Rust code you'll definitely see some function signatures that make your head hurt, even if they're vastly outnumbered by simple ones. A guarantee that the comprehension complexity of that part of your code will always be below some low ceiling is tempting.

Post by lmm » Fri, Oct 25, 2024, 11:22 AM UTC

gpderetta wrote: post #99

lmm wrote: post #94

Earlier quoted context omitted.

Nah. The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking, as is the idea that a project could continue to provide useful functionality without vulnerabilities becoming newly exposed. And the idea of a meaningfully safer C++ is something that has been tried and failed for 20+ years. Eventually everything will be rewritten in Rust or successor…

> The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking yet the idea that a project no longer actively developed will be rewritten in rust is not?

Post by simonask » Fri, Oct 25, 2024, 11:41 AM UTC

account42 wrote: post #101

The assumption here seems to be that the compiler/analyzer is only able to look at one function at a time. This makes no sense. Safety is a whole-program concern and you should analyze the whole program to check it. If anything as simple as the following needs lifetime annotations then your proposed solution will not be used by anyone: const int& f4(std::map & map, const int& key) { return map[key]; }

    fn f4(map: &'a Map, key: &i32) -> &'a i32 { ... }