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

51–60 of 157 posts

Re: Memory Safety

#51

Post by torginus »

II2II wrote: post #46
sealeck wrote: post #19

Earlier quoted context omitted.

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.

Commenting from the sidelines: Doesn't modern C++ offer the ability to write memory safe code? The primary distinguishing difference from Rust, on this front, is that Rust is memory safe by default (and allows them to override memory safety with code that is explicitly declared as unsafe) while C++ requires the developer to make a conscious effort to avoid unsafe code (without providing facilities to declare code as…

I think one of the fundamental differences in the SOTA C++ approach to memory safety (eg. extending unique/shared_ptr) and Rust is that C++ doesn't try to enforce having a single mutable reference to a variable and it still relies on strict aliasing heuristics, and so cannot claim to be fully deterministic. Still, use after free, and memory leaks should be impossible.

It'll still let you do a bunch of stuff Rust doesn't, which is up to the programmer to decide whether this is good or not.

Re: Memory Safety

#52

Post by AlotOfReading »

II2II wrote: post #46
sealeck wrote: post #19

Earlier quoted context omitted.

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.

Commenting from the sidelines: Doesn't modern C++ offer the ability to write memory safe code? The primary distinguishing difference from Rust, on this front, is that Rust is memory safe by default (and allows them to override memory safety with code that is explicitly declared as unsafe) while C++ requires the developer to make a conscious effort to avoid unsafe code (without providing facilities to declare code as…

    Doesn't modern C++ offer the ability to write memory safe code?
Can you name an example of a non-trivial C++ program that's memory safe? The only examples I can think of went to extraordinary lengths with formal methods and none of them are widely used.

Re: Memory Safety

#53

Post by woodruffw »

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.

I think Go is effectively memory safe. The relevant test is for the presence of exploitable memory corruption, and to my understanding that’s never been a real issue with Go.

Re: Memory Safety

#54

Post by pizlonator »

vlovich123 wrote: post #34
pizlonator wrote: post #17

Earlier quoted context omitted.

> 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…

By definition, C and C++ are memory safe as long as you follow the rules. The problem is that the rules cannot be automatically checked and in practice are the source of unenumerable issues from straight up bugs to subtle standards violations that trigger the optimizer to rewrite your code into what you didn’t intend. But yes, fil-c is a huge improvement (afaik though it doesn’t solve the UB problem - it just guarant…

> By definition, C and C++ are memory safe as long as you follow the rules.

This statement doesn't make sense to me.

Memory safety is a property of language implementations, which is all about what happens when the programmer does not follow the rules.

> The problem is that the rules cannot be automatically checked and in practice are the source of unenumerable issues from straight up bugs to subtle standards violations that trigger the optimizer to rewrite your code into what you didn’t intend.

They can be automatically checked and Fil-C proves this. The prior art had already proved it before Fil-C existed.

> But yes, fil-c is a huge improvement (afaik though it doesn’t solve the UB problem - it just guarantees you can’t have a memory safety issue as a result)

Fil-C doesn't have UB. If you find anything that looks like UB to you, please file a GH issue.

Let's also be clear that you're referring to nasal demons specifically, not UB generally. In some contexts, like CPU ISAs, UB means a trap, rather than nasal demons. So let's use the term "nasal demons".

C and C++ only have nasal demons because:

- Policy decisions. For example, making signed integer addition have nasal demons is because someone wanted to cook a benchmark.

- Lack of memory safety in most implementations, combined with a refusal to acknowledge what happens when the wrong kind of memory access occurs. (Note that CPU ISAs like x86 and ARM are not memory safe, but have no nasal demons, because they do define what happens when any kind of memory access occurs.)

So anyway, Fil-C has no nasal demons, because:

- I turned off all of those silly policy decisions for cooking benchmarks.

- The memory safety means that I define what happens when the wrong kind of memory access occurs: the program gets killed with a panic.

Re: Memory Safety

#56

Post by torginus »

websiteapi wrote: post #12
muricula wrote: post #10

Earlier quoted context omitted.

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?

>is there actually a programming language that makes race conditions impossible

It'd be very hard to make something that offers that guarantee in the real world. One of the most common, IRL exploitable race conditions are ones that involve multiple services/databases, and even if your programming language would have such a feature, your production system would not.

Re: Memory Safety

#57

Post by woodruffw »

steelbrain wrote: post #40

The mentions of curl on this website are misleading and/or outdated. Curl is dropping the rust/hyper backend. See https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

Is it? Curl dropped the hyper components, but they appear to support rustls as a backend. That work appears to have been done by Prossimo as well, and is conceptually grouped with it on the site.

(In other words: curl is using Rust, just not a specific Rust HTTP/1 backend anymore. But the site doesn’t limit its scope to just that backend.)

Re: Memory Safety

#59

Post by aw1621107 »

torginus wrote: post #51
II2II wrote: post #46

Earlier quoted context omitted.

Commenting from the sidelines: Doesn't modern C++ offer the ability to write memory safe code? The primary distinguishing difference from Rust, on this front, is that Rust is memory safe by default (and allows them to override memory safety with code that is explicitly declared as unsafe) while C++ requires the developer to make a conscious effort to avoid unsafe code (without providing facilities to declare code as…

I think one of the fundamental differences in the SOTA C++ approach to memory safety (eg. extending unique/shared_ptr) and Rust is that C++ doesn't try to enforce having a single mutable reference to a variable and it still relies on strict aliasing heuristics, and so cannot claim to be fully deterministic. Still, use after free, and memory leaks should be impossible. It'll still let you do a bunch of stuff Rust does…

> Still, use after free, and memory leaks should be impossible.

Use-after-free is still possible in modern C++ via std::span/std::string_view/etc. outliving the backing object.

Re: Memory Safety

#60

Post by hackermailman »

AlotOfReading wrote: post #9
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.

If we're being extremely strict, Python probably also shouldn't be on that list because the CPython runtime is written in C and has had issues with memory safety in the past. Ultimately, "memory safety" is a conversation about what a program is intended to do and what semantics the language guarantees that program will have when executed. For the vast majority of programs, you can be just as confident that your Go an…

Sometimes except I learned the hard way that if you write everyday Python math code it's actually variable-time arithmetic and totally unsuitable for applied cryptography, oops
Post reply on HN