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

71–80 of 272 posts

Re: Memory safety absolutists

#71

Post by jagged-chisel »

smj-edison wrote: post #21

This is perhaps a different take, but one reason I love Zig and C is because I've learned how to reason in pointers. I've worked with Rust in the past on a ~12,000 LOC side project, so I was all in with tree ownership and XOR mutability. But it turns out there's all sorts of delightful data structures that you can only express with unsafe in Rust. Intrusive doubly linked lists are the coolest thing ever. The fact tha…

> The fact that I can have a LRU cache that changes what's at the front by shuffling some pointers, while still keeping stable addresses so the hash map stays stable? That's freaking cool. Atomic operations with pointers for linked lists is really slick for implementing an allocator's free list between threads. Being able to walk a live heap using a breadth first search by just... following pointers, made the elegance of Dijkstra's algorithm come alive.

I feel like these kinds of things should be transformations that the compiler can use to turn Provably Safe code into performant code, i.e. you write the safe code and, once the borrow checker is happy, the compiler does its magic. I have no idea how to codify any of it into a compiler pass, or whether it's actually possible...

Re: Memory safety absolutists

#72

Post by himata4113 »

NBJack wrote: post #69
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…

If as a user you're willing to pay these library/application owners and premium to do so, by all means; this is a reasonable demand. But short of a massive campaign to educate and change minds, I can't see the average user caring enough.

My biggest gripe honestly is businesses rather than any particular opensource project, opensource projects can often get away with these issues getting caught by the many eyes looking at them before they ever make it to mainline.

Re: Memory safety absolutists

#73

Post by e2le »

bloaf wrote: post #11

As long as rowhammer is still out there, aint none of your memory safe. Fixing rowhammer is the memory safety absolutism I want to hear more about.

Defective memory is another issue to be aware of and somewhat common. Around 10% of Firefox crash reports are due to bit flips.

https://news.ycombinator.com/item?id=47252971

Re: Memory safety absolutists

#74

Post by [deleted] »

Animats wrote: post #56
rowanG077 wrote: post #52

Earlier quoted context omitted.

I agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.

The important thing from a performance standpoint is to be able to hoist bounds checks out of inner loops. This avoids a check on each iteration. Languages which have constructs such as for foo in bartab {} can usually hoist checks out of inner loops almost for free. I used to argue with the C++ committee about to when it's OK to catch an error early. If you write #define LEN 1000 int tab[LEN]; for (auto p = tab; p++…

[deleted]

Re: Memory safety absolutists

#75

Post by ssokolow »

saghm wrote: post #29
davidgay wrote: post #26

Earlier quoted context omitted.

> Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. No, it's been known since GC was invented. > In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". Having done all of my research on memory safety after Java was released, I find this stateme…

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?"

*nod* They're from before I started bookmarking rigorously, but in the early days of Rust, there was a sentiment in the blog posts from the people developing it that the point of Rust was "to give good ideas a second chance" and that Rust was intentionally boring and un-innovative.

Re: Memory safety absolutists

#76

Post by tptacek »

Once again, people are grappling with an axiomatic definition of "memory safety" and avoiding the fact that it's a term of art with a very specific meaning: comprehensive protection from The Memory Corruption Vulnerabilities, which include overflows, the lifecycle vulnerabilities like UAF and type confusion, and uninitialized variables.

To the extent Fil-C and Rust both address these vulnerabilities, and don't include design features that in any practical way admit them, they're memory safe. What always feels like is missing from these kinds of analyses is that there are lots of memory-safe programming environments. Almost every Java, Python, Ruby, Javascript, and Go program is memory safe, in the real meaning of the term.

The competition to lock in and promote adoption of the "most" memory-safe language is a category error... unless you do what every language-war argument does, and redefine the term.

Re: Memory safety absolutists

#77

Post by ssokolow »

rowanG077 wrote: post #52
muvlon wrote: post #50

Earlier quoted context omitted.

As a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.

I agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.

True... but if you go by what you're most likely to encounter, I'd argue the biggest unaddressed flaw in Rust is the lack of a current, maintained analogue to tools like Rustig! and findpanics, which would analyze your compiled, optimized binary and report any code paths which lead to panics.

I don't like having to contort my code to fit each unit of work into the API of `std::panic::catch_unwind` so I can responsibily distrust the transitive dependencies beyond the reach of my Clippy lints.

Re: Memory safety absolutists

#78

Post by antonvs »

rowanG077 wrote: post #52
muvlon wrote: post #50

Earlier quoted context omitted.

As a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.

I agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.

If you really believed that, you’d be programming in something like ATS, Idris, or Spark Ada. The reason that (I’m guessing) you don’t is that it takes a lot more effort to write general purpose code in those languages.

Rust is pretty much state of the art in this area for general-purpose, non-GC programming languages, and people still complain about the effort involved in writing memory-safe code with it.

If you really want complete memory safety, use a garbage collected language.

Re: Memory safety absolutists

#79

Post by ssokolow »

saghm wrote: post #57
yjftsjthsd-h wrote: post #51

Earlier quoted context omitted.

> To apply your logically consistently, you'd also have to throw out Go[1], Java[2], C#[3], and plenty of other languages Yes? Is Fil-C not obviously safer than those? > I guess you can define a logically consistent taxonomy of languages where Fil-C is the only "safe" language any everything else is unsafe, but then the burden is on you to prove that it's a useful way of thinking about them. Meanwhile, the way that p…

> It seems like "can switch on unsafe whenever" vs "has no escape hatches" is an obvious line in the sand and a very useful distinction with real world implications. Sure, although to me, the obvious distinction is that one of them gives you more flexibility (since neither Go nor Fil-C is at risk for someone accidentally writing unsafe code). > Why in the future? It exists and can be used right now. In fact, much of…

Bearing in mind that "there should be no room for a language above assembly and below Rust" (i.e. something like what C or C++ is to Python, Java, C#, etc.) was an intentional design decision for Rust which resulted in `unsafe`.

Re: Memory safety absolutists

#80

Post by 20k »

NBJack wrote: post #68
inigyou wrote: post #66

I think the "Fil-C is safer than Rust" thing is an understandable reaction to 10 years of Rust evangelists telling people they have to use Rust otherwise they're stupid and wrong.

We can learn a lot about memory safety from Rust. But if we can achieve the same dream of Fil-C for other more common languages that need it, Rust's popularity will likely wane.

Fil-C has a large performance impact though, and it'll always be reasonably significant. Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C#
Post reply on HN