ralfj

6 ms·

1.
by ralfj 1y ago
> "arbitrary concrete behavior" means that at this point anything can happen on the real machine. This implies that everything before this point has to behave according to the specification. "is impossible" is stronge
2.
by ralfj 1y ago
> They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages). For Java, there's no contradiction if you define data r
3.
by ralfj 1y ago
> The C definition is that "undefined behavior" can have arbitrary concrete behavior, not that a compiler can assume it does not happen. What is the difference between those? How does a compiler that assumes UB never happens v
4.
by ralfj 1y ago
Thanks! I added a reference to that in the blog post. Interestingly, in 2012 Rob Pike explicitly said that Go is "not purely memory safe" because "sharing is legal": https://go.dev/talks/2012/sp
5.
by ralfj 1y ago
It's impossible in safe Rust (modulo compiler bugs and things like using a debugger to poke in the program's memory from the outside). That's the key difference. Of course unsafe Rust is not memory safe. That's why it
6.
by ralfj 1y ago
> The rest is your bug; the variable values coming out of sync with each other, not maintaining the invariant among their values. If the language and its runtime let me break their invariant, then that's their bug, not mine. Thi
7.
by ralfj 1y ago
(EDIT: removed the first part since I realized you were replying to some comment further up, not my example.) > Rust has, unfortunately, changed the narrative so that people now believe memory safety is a property of the language, when i
8.
by ralfj 1y ago
See https://www.youtube.com/watch?v=QrrH2lcl9ew for a a presentation of Google's study, which found no measurable difference in productivity between teams using Rust vs Go.
9.
by ralfj 1y ago
Fair, I misunderstood then. :)
10.
by ralfj 1y ago
> The perception created by your article is that people shouldn't use Go because it's not memory-safe. Uh, where exactly am I saying or implying that? I am, in fact, saying that Go is much closer to memory-safe languages than t
11.
by ralfj 1y ago
> it met one common definition of "memory safety", which was essentially "have a garbage collector" This is the first time I hear that being suggested as ever having been the definition of memory safety. Do you have a
12.
by ralfj 1y ago
Yeah, Go is often listed with memory-safe languages, I know that. And yet when people define memory safety, Go usually fails to satisfy that definition. That's why I was asking for a definition of memory safety that would include Go.
13.
by ralfj 1y ago
You keep making arguments by assertion without giving sources, so :shrug: yeah this isn't going to go anywhere. I think we actually agree on all of the factual points here, we just don't agree on how languages should be categorize
14.
by ralfj 1y ago
Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any. (But also, it'd be kind of silly for every language to make up their own definition of memory safety. Then even C i
15.
by ralfj 1y ago
> There is plenty of undefined behavior that can't lead to violating memory safety. For example, in many languages, argument evaluation order is undefined. If you have some code like: You are mixing up non-determinism and UB. Sadly
16.
by ralfj 1y ago
Java also sometimes uses "memory safe" to refer to programs that don't have null pointer exceptions. So in that sense, Java isn't memory safe by construction either. These terms are used slightly differently by different
17.
by ralfj 1y ago
> Curiously, Go itself is unclear about its memory safety on go.dev. Yeah... I was actually surprised by that when I did the research for the article. I had to go to Wikipedia to find a reference for "Go is considered memory-safe&qu
18.
by ralfj 1y ago
> Another way to reach the same conclusion is to note that this post's argument proves far too much; by the definition used by this author, most other higher-level languages (the author exempts Java, but really only Java) also fail
19.
by ralfj 1y ago
Yeah, I can totally believe that this is not a big issue in practice. But I think terms like "memory safety" should have a reasonably strict meaning, and languages that go the extra mile of actually preventing memory corruption ev
20.
by ralfj 1y ago
Yeah I understand that that's how you like to use the term, you've been very clear about that. What I am curious about is whether that's just you. Because the source you gave last time, https://www.memorysafety.org
21.
by ralfj 1y ago
> While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at And yet Go violates the definition they give -- it doesn't prevent out-of-bounds accesse
22.
by ralfj 1y ago
> It reads 42h because that address is hardcoded, It is trivial to change this example into an arbitrary int2ptr cast. > Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Ru
23.
by ralfj 1y ago
PLT has used the term "type safety" for a very long time -- so "safety" does not imply a security perspective. And yes it is indeed very different from correctness. But the article doesn't claim that memory safety s
24.
by ralfj 1y ago
> So, while I can imagine that Miri could be best in class, that class itself has significant limitations. Sure -- but it's still better than writing similar code in C/C++/Zig where no comparable tool exists. (Well, for C
25.
by ralfj 1y ago
> This is different from no aliasing of Rust, where mutable references of even the same type may not alias. It is different, yes. I never said it was the same. Your claim was that the Rust model is more difficult, that needs more justifi
26.
by ralfj 1y ago
That doesn't let you treat data in-place at two different types, unless one of them happens to be char. So you still need to make a copy in many cases, e.g. to convert between an array of uint32_t and an array of uint16_t. In some case
27.
by ralfj 1y ago
Yes, exactly. I'd be surprised if it's 5% -- that's about the ratio of all unsafe code, and most unsafe code does not mix references and raw pointers. I think it's less than 1% of the overall code that has to worry abo
28.
by ralfj 1y ago
> it is inconsistent with "fearless concurrency" when the Rust stdlib has UB. It is not. "fearless X" only applies to safe code. Rust was always very clear about that. It turns out that in practice, if >90% of your
29.
by ralfj 1y ago
> And the rules of Rust have tripped up even senior Rust developers. Yeah, even senior Rust devs make mistakes. Thanks to Miri, we can catch such mistakes. No reasonable person would expect even senior Rust devs to be magic superheroes
30.
by ralfj 1y ago
> Can you confirm that the interaction between raw pointers and mutable references still requires care? Yes, that still requires care. > In C, you do not use any special keywords to opt into or opt out of TBAA, instead it is the rule

More ›