Now do type safety.
Or better concurrency safety. The real deal
I'm sorry but which Chrome 0-days in the last year have been concurrency bugs instead of type confusion?
Memory Safety
131–140 of 157 posts
Re: Memory Safety
#132Earlier quoted context omitted.
Does Rust not have race conditions?
Rust has double free concurrency bugs https://materialize.com/blog/rust-concurrency-bug-unbounded-... Lockbud: project detailing memory, concurrency bugs and panics for Rust. https://github.com/BurtonQin/lockbud USENIX paper on model checking for Rust OS kernels uncovered 20 concurrency bugs across 12 modules in projects like Redox OS and Tock, including data races, deadlocks, and livelocks https://www.usenix.org/sys…
You've linked to a bug that was unintentional and was fixed.
Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed.
Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
Re: Memory Safety
#133Earlier quoted context omitted.
> Generally speaking, different groups, different projects, etc. Well yes, but we're talking about the Rust people, which is why Typescript was a red herring to begin with. The complaint is that they've got a new hammer and then start seeing nails everywhere. > What I was thinking is that there have been efforts to make memory-safe dialects/variants/etc. of C/C++, but none of them really got significant traction in t…
> The complaint is that they've got a new hammer and then start seeing nails everywhere. Ah, my apologies for misreading the original comment I replied to then. > This was mostly because they didn't solve the performance problem. In the domains where that matters less, other languages did make significant inroads. Java, Python, etc. have significant usage in domains that before them were often C or C++. Which is true…
C# AOT is performant, is easy to use and has a small footprint. (Less than a megabyte executable without trickery. I am sure one could get much smaller if someone put effort into it.)
Re: Memory Safety
#134Earlier quoted context omitted.
Can I use the Java implementations in another language without significant headache?
It's possible in practice (at least more so than with Go), but it's highly unusual. Back when free Java became a thing, I used it at first to obtain a memory-safe TLS implementation. It worked out well, I think, but there is a strong tendency for the JVM to become the trunk of your application that holds everything together.
> at least more so than with Go
It's actually quite easy to create a C bindings for a Go library, using CGo and -buildmode=c-shared.
I'm not sure what effect the Go runtime has on the overall application, but it doesn't seem like it would be "less possible" than with Java.
Re: Memory Safety
#135This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace , it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort…
> it is not an inherent feature of the language, just the implementation
So what is it now? If the implementation is correct in allowing you to cause UB with data races, then this is very much a feature of the language, making the language not memory-safe. Alternatively, the implementation is buggy here, in which case there should be a bug report somewhere.
Is there such a bug report (github issue)? Is there a line in the spec saying this is the intended behavior?
Re: Memory Safety
#136Earlier quoted context omitted.
C and C++ as defined by their current standards are memory unsafe. You may argue that some specific implementations manage to stay as memory safe as they can get away with, but even then, features like union prevents a fully memory-safe implementation.
> C and C++ as defined by their current standards are memory unsafe. I don’t think the spec says one way or another (but please correct me if you find verbiage indicating that the language must be memory unsafe). It’s possible to make the whole language memory safe, including unions. It’s tricky, but possible. Someone else mentioned Fil-C but Fil-C builds on a lot of prior art. The fact that C and C++ can be memory s…
The standard(s) very often say that a certain piece of C code has undefined behavior. Having UB means that there is behavior that is not necessarily explainable by the standard. This includes e.g. the programming seemingly continuing just fine, the program crashing, or arbitrary code running as part of an exploited stack buffer overflow.
Now, certain implementations of C might give your more guarantees for some (or all) of the behavior that the standard says is undefined. Fil-C is an example of an implementation taking this to the extreme. But it's not what is meant when one just says "C." Otherwise I would be able to compile my C code with any of my standard-compliant compilers and get a memory-safe executable, which is definitely not the case.
Re: Memory Safety
#137Earlier quoted context omitted.
Rust has double free concurrency bugs https://materialize.com/blog/rust-concurrency-bug-unbounded-... Lockbud: project detailing memory, concurrency bugs and panics for Rust. https://github.com/BurtonQin/lockbud USENIX paper on model checking for Rust OS kernels uncovered 20 concurrency bugs across 12 modules in projects like Redox OS and Tock, including data races, deadlocks, and livelocks https://www.usenix.org/sys…
You've linked to a bug that was unintentional and was fixed. Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed. Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
I see, you wish to limit the domain. Do safety issues in the async runtime count ? Or is even "async Rust" out of your criteria ?
What about this one ? "Futurelock in Tokyo" ? https://rfd.shared.oxide.computer/rfd/0609
Re: Memory Safety
#138I find it strange that this web site completely ignores the Java ecosystem, which offers memory-safe implementations for most of the protocols and services listed.
Java does fine on memory safety, but does not do great on null safety (and overall invariant protection / "make invalid states unrepresentative" ethos), has difficult to harden concurrency primitives, and won't be adopted in many scenarios due to runtime cost and performance pitfalls. Future Valhalla work fixes some of these issues, but leaves many things spiky.
That's not a reason for this page to ignore the Java ecosystem, which extremely fits with Prossimo's mission.
Re: Memory Safety
#139Earlier quoted context omitted.
You've linked to a bug that was unintentional and was fixed. Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed. Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
I see, you wish to limit the domain. Do safety issues in the async runtime count ? Or is even "async Rust" out of your criteria ? What about this one ? "Futurelock in Tokyo" ? https://rfd.shared.oxide.computer/rfd/0609
> What about this one ? "Futurelock in Tokyo" ?
Deadlocks are not memory safety issues by the definition used in the OP. Furthermore, safe Rust is only intended to guarantee protection against data races, not race conditions in general.
Re: Memory Safety
#140Earlier quoted context omitted.
I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace , it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort…
The thing that annoys me more is the singular focus on memory safety as if nothing else matters. For example, by most definitions PHP is a "memory safe" language, but it's also full of poor design choices and the things written in it have a disproportionate number of security vulnerabilities. JavaScript is also classically modeled as a gelatinous mass of smoldering tires and npm seems to have been designed for the pu…
Memory safety as a term of art in software security is about eradicating code execution bugs caused by memory corruption. It's not a cure-all for software security. Most vulnerabilities in the industry aren't memory safety bugs, but empirically memory safety vulnerabilities are inevitable in software built in C/C++.