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

171–180 of 272 posts

Re: Memory safety absolutists

#171

Post by sirwhinesalot »

SkiFire13 wrote: post #158
sirwhinesalot wrote: post #150

I don't particularly care about Rust vs Fil-C shit flinging, I don't even see them as competing since they have effectively near opposite tradeoffs. You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. It would even be interesting to turn off some of Fil-C's expensive protections in the safe parts of the Rust code, making an average-of-both-worlds sort of solution. What I do care about are C…

> 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.

Re: Memory safety absolutists

#172

Post by tialaramex »

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…

Given you like pointers so much a dislike for Rust would make sense if Rust didn't have pointers, but it does and IMO as somebody who spent years getting paid to write in C, Rust's pointers are better.

I don't know if Zig has made any clear decisions about this (chime in any Zig experts) but in C [and C++] the pointers are crap because they're "zapped" when the thing pointed to is gone. Now of course in reality your compiler won't overwrite your pointer just because the standard says it could, but because the compiler knows it would be allowed to do that, it can optimise pointer tricks in surprising ways. To work around this, C and C++ provide pointer-sized integers and exhort you to do any tricks with those instead because there's no zap.

In Rust that's unnecessary, the pointers are just pointers, if the thing pointed at is invalidated, you mustn't dereference that pointer because it's not pointing at anything now, but you can still for example XOR it against another pointer. Clever pointer tricks are thus your responsibility as programmer, and you can just do them with pointers rather than needing this pointer-sized-integer workaround.

Re: Memory safety absolutists

#173

Post by whytevuhuni »

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.

Rust helps prevent some race conditions, but an unqualified "prevents race conditions" sounds like it eliminates them, hence why GP says it does not.

Re: Memory safety absolutists

#174

Post by inigyou »

dns_snek wrote: post #126
consumer451 wrote: post #23

Earlier quoted context omitted.

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

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

Re: Memory safety absolutists

#175

Post by inigyou »

uecker wrote: post #157
naasking wrote: post #153

Earlier quoted context omitted.

You wouldn't have to worry so much about running up to date software if memory safety were pervasive.

This is wrong as there are many other safety issues to worry about.

But memory safety is one of the big ones.

Re: Memory safety absolutists

#176

Post by kevincox »

rcxdude wrote: post #170
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…

Linked lists are cool but they are terrible for cache performance, so their apparently elegant performance characteristics are often illusory. And hybrid data structures which get you the best of both worlds are quite complicated to implement. I think that's why there's a general pressure against using them unless you have a very specific reason (and ideally some measurements) to demonstrate that they are a good opti…

Traversing a linked list is terrible for performance. But in cases like the cache you are only poping from the front, appending to the back or removing which are all quite fast and require little pointer chashing.

Cache cost of individual allocations can be an issue but that can also be mitigated with a good allocator and even without special care can be quite performant in many applications.

I agree the linked lists shouldn't be the first structure you reach to. But there are situations where they can perform very well.

Re: Memory safety absolutists

#177

Post by inigyou »

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…

Sadly due to cache friendliness, current conventional wisdom is that linked lists are so slow that a dynamic array of pointers is almost always faster even in cases when you'd think linked lists would be faster, such as frequent insertions in the middle.

Re: Memory safety absolutists

#178

Post by uecker »

inigyou wrote: post #175
uecker wrote: post #157

Earlier quoted context omitted.

This is wrong as there are many other safety issues to worry about.

But memory safety is one of the big ones.

Most people I know that had security incidents did not have this because of memory safety issues. But it does not matter, even without memory safety issues out of the picture, you would need to update your software and be wary of supply chain attacks.

(Actually, I can't remember a single incident where somebody I knew was directly affected by a memory safety issue)

Re: Memory safety absolutists

#179

Post by tialaramex »

rcxdude wrote: post #170
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…

Linked lists are cool but they are terrible for cache performance, so their apparently elegant performance characteristics are often illusory. And hybrid data structures which get you the best of both worlds are quite complicated to implement. I think that's why there's a general pressure against using them unless you have a very specific reason (and ideally some measurements) to demonstrate that they are a good opti…

Yeah, I'd blame mainly 2 factors for the continued undue influence of linked lists

1. CS professors teach them. The Programme Lead for our CS course still teaches linked lists as the first data structure in the DSA course. Does this type exist? Sure. Is it a good idea? Almost never. But you wouldn't think so from its prominence in the course materials.

2. The Linux kernel uses a LOT of linked lists. Multi-core atomic operations on mutable data, a nightmare you will probably avoid in your software is necessary for the OS kernel and so it has linked lists. Linux is very famous, but your software is almost certainly not an operating system kernel.

Re: Memory safety absolutists

#180

Post by zorobo »

robalni wrote: post #155
Panzerschrek wrote: post #152

Earlier quoted context omitted.

> we have to care about not using ages as shoe sizes and indexes with the wrong arrays. "Memory safe" languages usually don't help In languages even slightly better than C one can create a wrapper type for int/float with additional semantics like age, shoe size or something else. Since they are different types, using one in place of other isn't possible. This doesn't solve all problems, but at least can prevent silly…

Interesting, I have had ideas about having that feature in a language: being able to make subtypes, like "this is an integer but on the next level it is a shoe size". Can you give an example of such a language or how they usually do that?

Ada from day 1: Subtype with checks: https://www.adaic.org/resources/add_content/standards/05rm/h...

`type Shoe_Size is new Integer` defines a type incompatible with `type Age is new Integer`

Post reply on HN