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

Memory Safety

memorysafety.org

Post reply on HN
Print view View original

11–20 of 157 posts

Re: Memory Safety

#11

Post by K0nserv »

websiteapi wrote: post #3
codys wrote: post #2

This 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.

is go not memory safe? other than unsafe and other contrived goroutine scenarios, isn't it? I'm actually really curious - I've been writing go for just a couple years now and my understanding is the only ways for it to be unsafe are the two scenarios I described earlier.

Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic.

See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Re: Memory Safety

#12

Post by websiteapi »

muricula wrote: post #10
websiteapi wrote: post #3

Earlier quoted context omitted.

is go not memory safe? other than unsafe and other contrived goroutine scenarios, isn't it? I'm actually really curious - I've been writing go for just a couple years now and my understanding is the only ways for it to be unsafe are the two scenarios I described earlier.

Usually people are talking about race conditions. When you say contrived you're thinking races conditions are difficult to win and unrealistic but attackers who have a lot of money on the line spend the time to win all sorts of wild race conditions consistently.

is there actually a programming language that makes race conditions impossible (I am not being facetious, I actually do not know)? if the existence of races makes a language unsafe, then aren't all languages unsafe?

Re: Memory Safety

#13

Post by roblabla »

pizlonator wrote: post #8

> Languages that are not memory safe include C, C++, and assembly. False. C and C++ are not memory safe if you use the most common and most performant implementations, sure. At some point these folks are going to have to accept that caveat

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.

Re: Memory Safety

#14

Post by llmslave2 »

roblabla wrote: post #13
pizlonator wrote: post #8

> Languages that are not memory safe include C, C++, and assembly. False. C and C++ are not memory safe if you use the most common and most performant implementations, sure. At some point these folks are going to have to accept that caveat

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.

He's talking about Fil-c

Re: Memory Safety

#15

Post by llmslave2 »

codys wrote: post #2

This 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.

Or perhaps because you are using an uncommon definition for "memory safety".

Re: Memory Safety

#17

Post by pizlonator »

roblabla wrote: post #13
pizlonator wrote: post #8

> Languages that are not memory safe include C, C++, and assembly. False. C and C++ are not memory safe if you use the most common and most performant implementations, sure. At some point these folks are going to have to accept that caveat

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 safe is no secret to those who understand language implementation.

Re: Memory Safety

#19

Post by sealeck »

squirrellous wrote: post #18

[flagged]

This is a bit like saying everyone would be a bit less jaded if the plane staying in the air wasn't hung over the Boeing 737 MAX 8 designer's heads by certain communities and used as an existential threat to the company.

Re: Memory Safety

#20

Post by Dylan16807 »

jkdjfdsnjsdf wrote: post #5
codys wrote: post #2

This 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.

By that standard it also incorrectly categorizes rust as memory safe.

> By that standard

What standard?

Post reply on HN