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

131–140 of 272 posts

Re: Memory safety absolutists

#131

Post by qsera »

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…

You are right on the money! I have been saying this for a while.

Apart from the utility, it is also a lot of fun. So it would be a pity if people are told that these things are legacy and they should not try to use/implement them..

Re: Memory safety absolutists

#132

Post by rowanG077 »

antonvs wrote: post #78
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.

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…

I program mostly in Rust, Haskell and Python nowadays. I indeed would love to go gc-less dependently typed. But I work in a team where the code I build is expected to be maintained by other devs. And going that route is unfortunately not tenable.

Re: Memory safety absolutists

#133

Post by ssokolow »

xboxnolifes wrote: post #92
bastawhiz wrote: post #85

Earlier quoted context omitted.

That's really just not true. Easy counterexample: any codec should be written in a memory safe language. Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.

I kinda wish we didn't push with the term "memory safe", and instead had a push with "correct". If your software isn't memory safe, it does not work correctly. We should aim to have software that works correctly.

The word "correct" already had a meaning. Memory safety is a subset of correctness in the same way that Rust can't statically prevent race conditions but it can prevent a subset of them called data races.

Re: Memory safety absolutists

#134

Post by smj-edison »

pwdisswordfishq wrote: post #115
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…

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.

Rust allows you to use a literal iirc like r#raw, which helps with migration. This isn't too different from Zig's @"var" for example, which I'm glad modern languages have an escape hatch for naming things that don't parse normally.

Re: Memory safety absolutists

#135

Post by Panzerschrek »

pjmlp wrote: post #113
Panzerschrek wrote: post #107

The main problem of Fil-C or similar solutions is not that they provide absolute safety with no escape hatch (unlike languages with unsafe keyword). The problem is that they provide an excuse to keep using terrible programming languages like C and C++ allowing memory safety issues in the first place.

Yeah, but who's going to rewrite LLVM in Rust, which rustc relies on? Yes there is Cranelift, and?

In case of such projects like LLVM C++ usage can be tolerated. But for new code or smaller codebases a better alternative should be considered.

Also Fil-C can't be used for LLVM anyway, since performance and memory consumption overhead is way too much. Nobody wants clang/rustc working 4x slower and consuming 2x more memory.

Re: Memory safety absolutists

#136

Post by ssokolow »

pwdisswordfishq wrote: post #115
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…

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.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Memory safety absolutists

#137

Post by smj-edison »

jagged-chisel wrote: post #71
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 eleganc…

There's some interesting work going on with this with Metamath Zero[0], where he's working on verifying everything down to the compiler, to make sure the compiler always emits correct code. His language, Metamath C, also allows for refinement types, which means you can prove certain properties. It's still in its infancy, but I've been watching it from the sidelines for a bit now.

Though in terms of practicality, Graydon Hoare has mentioned in the past that he isn't a big fan of complex systems, and so it's better to have a simple type system that covers 95% of the cases, and an escape hatch when it doesn't. I think that's still a fair assessment, but I've fallen down the proof rabbit hole so I am curious to see how far it could be pushed.

[0] https://github.com/digama0/mm0

Re: Memory safety absolutists

#138

Post by pjmlp »

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.

All the safety improvements of 21st century wannabe C replacements, were already available in NEWP(1961), PL/I (1964), Mesa (1976), Modula-2 (1978), PL.8 (1982), Ada (1983), Object Pascal (1986), among many other lesser known ones.

However none of them had an OS available in source code for the symbolic price to send tapes around to universities.

Additionally, the remark that the UNIX and C authors themselves did not stop there, and their latest mark on the computing world was the Go programming language, after Limbo, and the acknowledgement that designing Alef without a GC was a mistake.

Probably they would not had to reboot Plan 9 OS design into C.

Re: Memory safety absolutists

#139

Post by smj-edison »

safercplusplus wrote: post #105
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…

Well, there is another safe option for flexible pointers if you can compile as C++ [1]. In C++ you can have non-owning "smart" pointers with run-time-checked lifetimes [2][3]. Importantly, there is no run-time overhead to dereference them. (That is for the "never-null" versions, otherwise there's a null check.) Assignment has additional run-time cost, but pointer assignments are generally much less prevalent in perfo…

Interesting, this is pretty cool! I'm guessing it doesn't work with pointer to int casts though? I'm using NaN packing, so I necessarily have to cast it to an integer.

EDIT: though I'm considering switching to a tag + 64 bit union, because of 54 bit addressing and pointer tagging. It makes it tricky to get my data layout right though, since it makes all of the structures larger.

Re: Memory safety absolutists

#140

Post by Panzerschrek »

robalni wrote: post #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 sa…

> but it's still possible to use memory incorrectly

Only by misusing unsafe. Using it in regular programs actually isn't that necessary. In languages like C you have unsafe code almost in every line.

> My understanding is that a memory bug is when you use memory in an unintended way

Memory safety rules are more strict and formalized than you think. Memory safety issues are typically reading uninitialized memory (or strictly speaking changing observable behavior based on contents of uninitialized memory), reading/writing memory after it have been freed (free/delete call or out-of-scope going for local variables), concurrent unsynchronized memory access.

> No compiler or tool can make sure you don't write to or read deallocated memory

I am author of a programming language, where you can't write to or read deallocated memory, unless you misusing unsafe.

> no compiler can read your thoughts

But many languages more complex than C have powerful features allowing telling the compiler your about intents. At least partially.

> Memory allocation is relative. In a sense, no program that runs under an operating system can use deallocated memory

You are mixing two different concepts. One is memory model of the abstract machine defined by the specification of a language and other is the OS processes model. They have much in common, but there are a lot of differences.

> So again, everything is safe if you use it as intended

Such mindset is considered harmful, since it provides an excuse to use languages where making mistakes is easy (like C).

Post reply on HN