Mitigating Memory Safety Issues in Open Source Software

Post by Cullinet » Thu, Feb 18, 2021, 8:27 PM UTC

jaas wrote: post #161

lrossi wrote: post #3

What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. Correct me if I’m wrong, but that’s my understanding of the rather terse article. I would rather have the original maintainers funded and still in control of the many pieces that form the basis of the major Linux distribut…

(Executive Director of ISRG here) > What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. This's not what's happening. Here's what is: ISRG plans and coordinates investments in moving open source software to memory safe languages. We have a strong preference for working on th…

Post by saagarjha » Thu, Feb 18, 2021, 8:32 PM UTC

rurban wrote: post #126

A worthwhile goal. But not in a memory unsafe language, please. There's hype and there are lies: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

Post by [deleted] » Thu, Feb 18, 2021, 8:37 PM UTC

Liquid_Fire wrote: post #115

bluGill wrote: post #102

Earlier quoted context omitted.

Then you don't know anything about C++, only the C legacy it is built on. Modern C++ has good data structures and good memory management. To be fair actually using those features of C++ instead of the C legacy is still catching on. Most instructors aren't even teaching it. Using C in C++ is like using unsafe everywhere in rust - you can do it, but you lose all the advantages.

Even if you stick to "modern C++" and never use C-style pointers, arrays, enums or unions, it is still trivial to have memory errors in C++.

Post by nimmer » Thu, Feb 18, 2021, 8:44 PM UTC

floatboth wrote: post #103

nimmer wrote: post #97

Earlier quoted context omitted.

Nim is not using GC anymore [1], is memory safe and support formal methods [2] It's also introducing isolation [3] to provide safe multithreading similar to Rust's sendable. [1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... [2] https://nim-lang.org/docs/drnim.html [3] https://github.com/nim-lang/RFCs/issues/244

From [1]: > ORC is Nim’s all-new cycle collector based on ARC. It can be considered a full-blown GC since it includes a local tracing phase (contrary to most other tracing GCs which do global tracing). ORC is what you should use when working with Nim’s async because it contains cycles that need to be dealt with. Sooooo unless you > disable the GC and do manual memory management, but then you lose access to most of th…

Post by c-cube » Thu, Feb 18, 2021, 9:06 PM UTC

Arch-TK wrote: post #162

tediousdemise wrote: post #63

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package managers end up not really solving the problem they are designed to solve, and are a huge attack vector. Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. C++, on the other hand, has a variety of choices for build sy…

At this point if you stick to a limited subset of C++ and don't go too deep you can get a perfectly safe language which is powerful and performant. If you want a safer language with in my opinion a far better type system than anything Rust could possibly achieve at this point you can use Ada. But why not those two options? Old, smelly and most importantly, difficult to deal with dependencies. You have to actually thi…