Live data from Hacker News

Memory safety absolutists

itsallaboutthebit.com

121–130 of 272 posts

Re: Memory safety absolutists

#121

Earlier quoted context omitted.

> you can prevent all memory safety errors by using a garbage collector Garbage collection and a higher-level language that controls allocations handles 2/3 of the memory-safety problem space (using memory you shouldn't via use-after-free, or using memory you shouldn't before allocation/via arbitrary address access), but the other 1/3 isn't addressed by GC: out-of-bounds access on properly-allocated structures. GC-or…

You forgot the other three thirds GC doesn't handle: in-bounds writes to memory currently in use by another processor. One of the basic ideas behind Rust's memory safety story is that eliminating race conditions necessarily requires a good memory safety story, especially regarding temporal memory safety. ...of course, the managed code languages had an answer to this: put a lock on every managed object you allocate. B…

Fearless concurrency only works as advertised when those data structures aren't exposed via the MMU to other processes, or are handles to resources like files or database connections, where each thread can do whatever they want without type system checks.

All relevant scenarios when the goal is systems programming.

Re: Memory safety absolutists

#122

> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Unfortunately, I've never seen a version of this data targeting modern C++ (>=11, with smart pointers, already 15 years old).

Because it doesn't exist, I have never seen modern C++ in real life as in conference slideware.

Most projects keep being full of C idioms, regardless of how much advocacy we keep pushing for.

Re: Memory safety absolutists

#123

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…

So how do I take a shared reference to a variable named "raw"? Complicating the grammar for no good reason. This should have stayed a macro.

`raw` is a contextual keyword.

Re: Memory safety absolutists

#124
post #78

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.

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

Additionally, there are plenty of garbage collected languages with support for doing low level stuff, or RAII, when it is really required.

Re: Memory safety absolutists

#125
The article points out what I think is the crux of the discussion: With Fil-C they become crashes. Errors manifest at runtime, not at compile time.

I realized some time ago when I talk to people about rust, I don't really mention memory / thread safety in a security context, I mention them in a reliability context. Compile-time checks mean I basically never spend time debugging runtime crashes, and generally can count on the compiler to catch memory and thread safety issues before the program ever runs, and this saves me time and aggravation in production. I care about security, but I care more about reliability, and rust compile-time checks mean my software is reliable in a way that runtime-checked languages just aren't.

This applies to lots of languages. Every time I hit a runtime crash in python, or ruby, or js I die a little inside. Even though they are memory-safe because they're garbage collected, I still waste time debugging runtime errors.

Re: Memory safety absolutists

#126

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.

> 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 more than using a certified I-beam makes someone a "Civil Engineer". What matters is that the finished structure/program meets the explicit and implicit requirements of safety, functionality, durability, cost, etc.

Not to mention that complex reliable systems are usually engineered out of much less reliable components.

Re: Memory safety absolutists

#127
post #9
post #8

It's annoying how many comment sections online are now just Rust vs Fil-C / Zig flamewars, and the creators of those languages are deliberately fanning the flames. I also feel there's a second dimension to the politics, where Rust is the "woke" language and C / Zig / Odin are now the "anti-woke" languages. At least, going by their most vocal online communities. I'm sure offline there's still engineering decisions bei…

Could you point me at the members of the Rust project doing so? I'd want to have a word with them (I'm a member of t-compiler).

They aren't. It's some random rust users vs the leader of the Zig project, leader of the Fil-c project, the head of community at Zig, etc. But they like to pretend there is an equivalence on the Rust side.

Re: Memory safety absolutists

#128
This made me think and reflect, thank you.

Not so much about language design as how easy it is to take a defensive position on something we are comfortable with when it's challanged. This prohibits growth.

When someone suggests you have been doing something the wrong way or has a new idea, it's usually better to hear them out and take what knowledge you can from them, even if they weren't actually trying to help you.

Anyways, thanks again

Re: Memory safety absolutists

#129
post #9
post #8

It's annoying how many comment sections online are now just Rust vs Fil-C / Zig flamewars, and the creators of those languages are deliberately fanning the flames. I also feel there's a second dimension to the politics, where Rust is the "woke" language and C / Zig / Odin are now the "anti-woke" languages. At least, going by their most vocal online communities. I'm sure offline there's still engineering decisions bei…

Could you point me at the members of the Rust project doing so? I'd want to have a word with them (I'm a member of t-compiler).

Sorry for not being clear, I meant the creators of Fil-C and Zig (since those are the ones mentioned in the article)

Re: Memory safety absolutists

#130
I don't know if there can be any memory safe languages. Programming is always unsafe because you can always make mistakes. The best we can do is to use tools that help us avoid the common mistakes.

As an example of that, the rust compiler helps the programmer to avoid many mistakes but it's still possible to use memory incorrectly and the tool is only safe as long as you use it as intended. You could say that C is safe too as long as you use it as intended and make no mistakes. The only problem is that it's hard to use it as intended and make no mistakes.

So let's think about what memory safety could mean. My understanding is that a memory bug is when you use memory in an unintended way. An example of that is when you write to memory after you have deallocated it, which means after you have decided not to use it any more.

No compiler or tool can make sure you don't write to or read deallocated memory, because whether it's allocated depends on what your intention is, and no compiler can read your thoughts. They can only give you a tool (like functions for allocating and deallocating memory or compiler checks) and hope that you will use that tool in a way that reflects your intention. One problem is that those tools are not always sufficient to keep track of your intentions and you may not always use them as intended.

Memory allocation is relative. In a sense, no program that runs under an operating system can use deallocated memory, because when they read or write to memory that has not been mapped to the process, they crash. In a sense, even "safe" rust can use deallocated memory; let's say you have an array of 10 integers and you decide that the fifth integer should not currently be used, you have then deallocated it on a level where the available tools can not help you, but you can of course still access that memory.

So again, everything is safe if you use it as intended and nothing is safe if you use it in other ways. Safety depends on how well the code matches your intentions. Remember that programming always happens in layers and no tool can cover all of them. It's not even clear what "all layers" would mean or how many there are in a program.

Post reply on HN