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

Memory safety absolutists

itsallaboutthebit.com

Post reply on HN
Print view View original

241–250 of 272 posts

Re: Memory safety absolutists

#241

Post by saghm »

pjmlp wrote: post #118
saghm wrote: post #29

Earlier quoted context omitted.

Yeah, my understanding (which is not from first-hand experience) is that a huge part of the origin of Rust was that there was a lot of research in memory safety techniques that had been going mostly unused by mainstream languages, so the idea was "Why not try to make a language using some of it?"

AT&T was already doing that as language to replace C, Cyclone. AT&T even had a full OS, where C only had minor role, the microkernel and Dis VM/JIT, with the whole userpace implemented in Limbo, designed by the creators of UNIX and C.

Interesting! I hadn't heard of Cyclone before.

Re: Memory safety absolutists

#242

Post by saghm »

Bisuta wrote: post #119
pjmlp wrote: post #118

Earlier quoted context omitted.

AT&T was already doing that as language to replace C, Cyclone. AT&T even had a full OS, where C only had minor role, the microkernel and Dis VM/JIT, with the whole userpace implemented in Limbo, designed by the creators of UNIX and C.

Good reminder that memory-safe alternatives to C aren't new. Rust may have won more because of ecosystem and timing than because it was the first to address the problem.

To clarify, I didn't mean to imply that there were never any memory-safe alternatives to C before Rust (and re-reading my comment, I still don't think it sounds like that's what I was trying to say, but if that's how people are reading it, then I didn't do a good enough job of making that clear). I was trying to say that my understanding was that Rust was trying to take advantage of research ideas that had been introduced in the past decade or so but hadn't been applied much, which is a more narrow claim than it being the first one to try to tackle the problem at all.

As the parent comment indicates, it seems like there might have been more languages that were less known that did try to apply some of these ideas, so maybe I'm misremembering the history that I had heard, or maybe I did remember what I heard right, but the people who originally expressed it were similarly unaware that some of it had been tried already. Hearing more context about the time period I was referring to is definitely interesting, and I appreciate it being shared!

Re: Memory safety absolutists

#243

Post by nwah1 »

CHERI seems to accomplish much of what Fil-C does, in-hardware. And removes some of the trust from the entire build toolchains in your entire supply chain, because memory-unsafety cannot be stealthily inserted.

Re: Memory safety absolutists

#244

Post by SkiFire13 »

adhamsalama wrote: post #169
SkiFire13 wrote: post #165

Earlier quoted context omitted.

> One of the basic ideas behind Rust's memory safety story is that eliminating race conditions Rust does not prevent race conditions. You're getting confused with data races. However GC's solution to data races (make every load/store act as very relaxed atomic instructions) makes race conditions much easier to write.

Rust does prevent race conditions.

Is this the classic "split out obviously wrong facts to get corrected"?

I'll take the bait then. Here's rust official documentation stating that it doesn't prevent race conditions: https://doc.rust-lang.org/nomicon/races.html

Re: Memory safety absolutists

#245

Post by SkiFire13 »

sirwhinesalot wrote: post #171
SkiFire13 wrote: post #158

Earlier quoted context omitted.

> You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. Isn't this what MIRI already does?

Partially yes. Fil-C goes further in creating an entire ecosystem of Fil-C compiled "legacy" libraries, meaning all the unsafe FFI your Rust code does into C is also safe, and even many linux syscalls. Miri is meant as more of a sanitizer type tool that you use during development to catch bugs. Fil-C is a platform you compile your entire Linux distro with for use in production.

I thought you meant to use Fil-C as a kind of sanitizer too.

I don't see a point in running Rust code in Fil-C. Due to the way Fil-C works it won't be enough to check the `unsafe` statements, so you'll pay the performance tax on safe code too (onto which you already paid the borrow checker tax!)

Re: Memory safety absolutists

#246

Post by pjmlp »

inigyou wrote: post #174
dns_snek wrote: post #126

Earlier quoted context omitted.

> memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. I wouldn't go that far, what matters is the finished whole. Memory safety of the finished program is a critical factor and using a memory safe language makes it easier to achieve that goal. However simply using a memory safe language doesn't make you a "Software Engineer" any mor…

Overall safety matters. Memory safety is just one factor. Log4Shell happened in Java, a GC language without pointer arithmetic.

Using seat belts is just one factor. People still die while wearing one, so it should not be compulsory.

Is how this kind of arguments always get received by security folks.

Re: Memory safety absolutists

#248

Post by thunderfork »

pizlonator wrote: post #212
drogus wrote: post #149

Earlier quoted context omitted.

I don't have an obsession with you. I haven't read the entirety of your social media presence, but almost every time I see a discussion about Rust on Twitter, especially involving Fil-C, I see your criticism of Rust, without much nuance. To be honest, seeing your replies emphasizing Rust's memory unsafety under pretty much every tweet I've seen about the subject felt like an obsession with Rust, to me. The problem I…

Before I started talking about Fil-C, discussions about Rust’s memory safety lacked nuance: folks claimed that if you just compiled your code in Rust then it would be memory safe. I have added the nuance. Folks now understand that there are limits to Rust’s memory safety. What have you added to the conversation? Nothing.

>What have you added to the conversation? Nothing.

This doesn't strike me as particularly constructive discourse

Re: Memory safety absolutists

#249

Post by goalieca »

consumer451 wrote: post #23
himata4113 wrote: post #2

My biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum. Now as a software d…

It seems to me that memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. However, I should probably pipe down, as I would not call myself either one.

There are engineering standards where dynamic allocation and especially garbage collectors are banned. C is actually a perfectly approved language in these cases.

Re: Memory safety absolutists

#250

Post by aw1621107 »

afdbcreid wrote: post #103
aw1621107 wrote: post #65

Earlier quoted context omitted.

> Like why do I need to use `addr_of_mut!`? As of Rust 1.82.0 [0] you no longer need to! > I'm sure there's a good reason, as Rust tends to think these problems through, but it's very unintuitive compared to returning `&mut`. The addr_of_mut docs [1] give a pretty decent explanation of its reason for existence; in short, it lets you get a pointer to something without needing to create potentially-invalid intermediate…

> > Like why do I need to use `addr_of_mut!`? > As of Rust 1.82.0 [0] you no longer need to! That's true but misleading. I'm pretty sure the question was why a normal reference is bad. You don't need `addr_of_mut!()`, but you do need `&raw mut`.

> I'm pretty sure the question was why a normal reference is bad.

Oh, completely missed that interpretation. I think in that case it comes down to references being incompatible with the desired semantics for an intrusive list - & doesn't work if you want to modify what you're pointing to, and &mut doesn't work since you may want multiple things to be able to point to and modify whatever you're pointing to.

Post reply on HN