Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no memory safety without thread safety

ralfj.de

Post reply on HN
Print view View original

511–517 of 517 posts

Re: There is no memory safety without thread safety

#511

Post by kiitos »

ralfj wrote: post #394
Thaxll wrote: post #382

Earlier quoted context omitted.

Go is memory safe, what do you think of: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... U.S. and International Partners Issue Recommendations to Secure Software Products Through Memory Safety They recommand Go among other language in their paper. https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE...

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.

I suppose Go's notion of memory safety is satisfied by forbidding pointer arithmetic, and, maybe somewhat transitively, preventing arbitrary out-of-bounds access to memory. It definitely satisfies this notion of memory safety. Maybe this notion of memory safety is not considered to be correct, or relevant, or whatever, by whomever. That's fine.

Re: There is no memory safety without thread safety

#512

Post by kiitos »

rowanG077 wrote: post #380
tptacek wrote: post #369

Earlier quoted context omitted.

You're just wrong about this. The ability to write contrived code that does an out-of-bounds write, or to induce crashes, doesn't violate the notion of "memory safety" as an ordinary term of art.

Did you consider that the organization can be wrong? > Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used. Since memory safety bugs are often security issues, memory safe languages are more secure than languages that are not memory safe. That is the definition they give. Since Go does not "prevent programmers from in…

> Memory safety is not a spectrum. You are either memory safe or unsafe.

if there is one takeaway from this discussion, i think it must be that memory safety does not have any single, commonly-accepted, or objective definition -- and that it is pretty obviously a spectrum, not a boolean

Re: There is no memory safety without thread safety

#514

Post by int_19h »

dontlaugh wrote: post #505
BlackFly wrote: post #504

Earlier quoted context omitted.

No, rust forces you to use a mutex but nothing will prevent you from making the mutex too small and creating tearing in your own data structures by sequentially modifying things covered by mutexes so that in between acquisition of the locks you are violating invariants. The borrow checker certainly helps however, but not without cost that was finally minimized when the scoped threads api came along. Java has a very s…

You didn’t describe any data races. What Rust prevents is very specific.

OP described situations where you get observable invariant violations because of torn non-atomic writes. This is basically any case involving e.g. copying of variables that are larger than whatever's atomic for a given architecture. Say, a struct of 4 isize.

Re: There is no memory safety without thread safety

#515

Post by rowanG077 »

kiitos wrote: post #512
rowanG077 wrote: post #380

Earlier quoted context omitted.

Did you consider that the organization can be wrong? > Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used. Since memory safety bugs are often security issues, memory safe languages are more secure than languages that are not memory safe. That is the definition they give. Since Go does not "prevent programmers from in…

> Memory safety is not a spectrum. You are either memory safe or unsafe. if there is one takeaway from this discussion, i think it must be that memory safety does not have any single, commonly-accepted, or objective definition -- and that it is pretty obviously a spectrum, not a boolean

I could agree to that if the people who claim it would at least put it in their definition. But as it stands it indeed is a boolean. You have to give a definition of something like:

"Memory safety denotes the degree to which a programming language guides and protects developers from memory‑related errors—ranging from minimal, manual checks to comprehensive static and runtime enforcement—through mechanisms like strong typing, ownership or borrow checking, and garbage collection."

And then also include modern C++ in their lists. because by all accounts it is memory safe by that definition.

Re: There is no memory safety without thread safety

#517

Post by mrkeen »

philosophty wrote: post #209
mrkeen wrote: post #110

Earlier quoted context omitted.

The only decisions that matter for languages that get adopted are the decisions that cause adoption. JS went without static types, Go went without generics, PHP was just a tool for reducing html boilerplate. New languages love to stick null right in there. Rust isn't what Graydon Hoare wanted it to be. Chris Lattner called Swift a failure. It's all up for criticism.

Sure, there are valid criticisms of anything but without understanding they're unlikely to be useful or correct.

Without criticism there's no understanding, just propaganda.
Post reply on HN