• perviouslyiner@lemmy.world
    0·
    20 days ago

    Seems excessive to convert everything to rust when you can use std::shared_ptr and std::weak_ptr to eliminate the memory safety issue?

    • arendjr@programming.devOP
      0·
      20 days ago

      Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.

        • robinm@programming.dev
          0·
          16 days ago

          Is it possible to do in Rust?

          Yes

          Is possible to do in Rust, by mistake, and not easily caught by a review?

          Definitively not.

            • robinm@programming.dev
              0·
              12 days ago
              void foo() {
    std::vector v = {0, 1, 2, 4};
    const auto& ref = v[1];
    add_missing_values(v);
    std::cout << ref << "\n";
}

void add_missing_values(std::vector<int>& v) {
    // ...
    v.push_back(3);
}

              Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.

              It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)

                • robinm@programming.dev
                  0·
                  9 days ago

                  I think you have a hard time understanding the différence between “not possible” and “much harder”.

                  In Rust, the code does not compile.

                  In C++ the code compile, but

                  • if you have a test case
                  • this test case triggers the bug (it is not guarateed to properly reproduce you production environment since it depends on the parameters of the allocator of your vector)
                  • you use ubsan

                  … then the bug will be caught.

                  Yes it is possible, noone says the opposite. But you can’t deny it’s harder. And because its harder, more bugs get past review, most notably security bugs as demonstrated again and again in many studies. The

  • wewbull@feddit.ukEnglish
    0·
    20 days ago

    That sounds like policy written by somebody who has no idea what the reality of software development is.

    1 year to rewrite critical software in a new language?

    • BlazeDaley@lemmy.world
      0·
      20 days ago

      It’s one backed by a lot of data. One example is from the Android project.

      The percent of vulnerabilities caused by memory safety issues continues to correlate closely with the development language that’s used for new code. Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop.

      https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

      There’s an argument that critical infrastructure software vendors are already meeting standards for basic, non-memory related items. Yes, there are other categories, but memory safety is one that’s harder to verify. Moving to memory safe languages is an ensure a category of correctness. This excludes usage of unsafe escape hatches.