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

41–50 of 157 posts

Re: Memory Safety

#41

Post by redbeeswimming »

Dylan16807 wrote: post #39
redbeeswimming wrote: post #35

Earlier quoted context omitted.

> The website prioritizes programs with 98% safe code over programs with 0% safe code. Please explain this section of the Rustonomicon. https://doc.rust-lang.org/nomicon/working-with-unsafe.html > This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against…

If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand. "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code. When I wrote "98% safe code" I meant the code that can be automatically verifi…

> If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand.

More or less correct, but in principle, it also requires modules to have proper encapsulation and interfaces. Otherwise, an interface could be made that enables safe API functions to cause memory unsafety if called incorrectly.

> "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code.

But https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo... indicated that maybe up to 45 files include unsafe code. That is quite a lot of files. How many modules might that touch? How large are those modules?

Re: Memory Safety

#42

Post by AlotOfReading »

vlovich123 wrote: post #37
AlotOfReading wrote: post #9

Earlier quoted context omitted.

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…

No, because then no language would be included, including Rust. Implementation bugs are not treated the same as integral parts of the language as defined by the standard. Python is defined as memory safe.

I understand this website as focusing on unsafety in a more practical sense of writing your stack in memory safe ways, not in the sense of discussing what's theoretically possible within the language specs. After all, Fil-C is standard compliant, but "run everything under Fil-C" is not the argument it's making. The most common language runtime being memory unsafe is absolutely an applicable argument here, mitigated only by the fact that it's a mature enough runtime that memory issues are vanishingly rare.

Re: Memory Safety

#43

Post by redbeeswimming »

Dylan16807 wrote: post #39
redbeeswimming wrote: post #35

Earlier quoted context omitted.

> The website prioritizes programs with 98% safe code over programs with 0% safe code. Please explain this section of the Rustonomicon. https://doc.rust-lang.org/nomicon/working-with-unsafe.html > This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against…

If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand. "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code. When I wrote "98% safe code" I meant the code that can be automatically verifi…

> When I wrote "98% safe code" I meant the code that can be automatically verified by the compiler. I wish the terminology was better.

That depends on what is meant by "automatically verified by the compiler". The compiler cannot generally verify outside-unsafe code that modifies invariants that inside-unsafe code might rely on to have memory safety, for instance.

Re: Memory Safety

#45

Post by Dylan16807 »

redbeeswimming wrote: post #43
Dylan16807 wrote: post #39

Earlier quoted context omitted.

If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand. "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code. When I wrote "98% safe code" I meant the code that can be automatically verifi…

> When I wrote "98% safe code" I meant the code that can be automatically verified by the compiler. I wish the terminology was better. That depends on what is meant by "automatically verified by the compiler". The compiler cannot generally verify outside-unsafe code that modifies invariants that inside-unsafe code might rely on to have memory safety, for instance.

I mean the portion of the code that has no write access to those fragile invariants. At minimum, this includes all modules that don't have unsafe blocks.

Re: Memory Safety

#46

Post by II2II »

sealeck wrote: post #19
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.

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 safe or unsafe). While this means that C++ is problematic, it does not make Rust automagically safer - particularly when interfacing with C/C++ code (as would be the case when interfacing with Linux syscalls or most C or C++ based libraries).

I guess what I'm saying is that Rust is great when dealing exclusively with Rust libraries since it is either memory safe by default or because it is easier to audit (since it is either declared explicitly or implicitly as unsafe). On the other hand, it is not guaranteed to be memory safe. While this may sound like nitpicking, the distinction is important from the perspective of the end user who is unlikely to ever audit the code yet may be swayed by being told that it is written in a memory safe language.

Re: Memory Safety

#47

Post by bgwalter »

The annual report of this org is pretty underspecified. There are numerous directors. Are they getting paid under "ops & admin" (11%)? Is "advancement" (12.3%) marketing?

Prossimo gets 6.8%. Does that money go to programmers? Are people whose works are being rewritten and plagiarized offered money to do the rewrite themselves or does it go to friends and family?

Why does an org that takes donations not produce a proper report?

Re: Memory Safety

#48

Post by ChadNauseam »

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…

All languages offer the ability to write memory-safe code. It's just that doing so is very difficult in C and C++. The benefit of Rust isn't really the assurance of safety that's provided by not using the `unsafe` keyword. After all, pretty much all Rust programs do use the `unsafe` keyword. The benefit of Rust is a combination of many design decisions that make it easy to write safe code.

For example, everyday operations in Rust are almost all defined. But in C++, it is extremely easy to run into undefined behavior by accident and make your code do something bizarre. On the practical side, I have never ever gotten a segfault when writing rust, but have many times in C++.

Re: Memory Safety

#49

Post by coffeeaddict1 »

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…

> C++ requires the developer to make a conscious effort to avoid unsafe code

The problem is much worse than how you put it. I've written C++ for more than a decade and it's painful to constantly having to worry about memory safety due to enormous complexity of the language. Even if you are super diligent, you will make a mistake and it will bite you when you expect it the least. Relying on clang-tidy, non-default compiler flags, sanitizers and other tools is not only not enough, but a constant source of headache on how to integrate them with your build systems and project requirements.

Re: Memory Safety

#50

Post by adapower »

sealeck wrote: post #19
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.

A better analogy might be how Ada was hung over the heads of those using C and C++, to the point of Ada being mandated by law in certain niches.

And then Ada software caused the loss of US$370 million with Ariane 5.

Post reply on HN