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

201–210 of 272 posts

Re: Memory safety absolutists

#201

Post by inigyou »

userbinator wrote: post #99
inigyou wrote: post #13

Earlier quoted context omitted.

ECC memory fixes rowhammer. And random bitflips. Everyone should have ECC memory, but Intel disagrees because they are greedy. My system sometimes detects a few bitflips per day.

My system sometimes detects a few bitflips per day. Perhaps you should replace your RAM, or it's a sign that you have a massive source of radiation lurking somewhere?

I assumed this is just normal in DDR5 and the reason I only had motherboards with ECC to choose from. I do have quite a lot of it.

It wouldn't be the first time engineers pushed something close to the unreliability limit and compensated with a mechanism to make it more reliable.

Re: Memory safety absolutists

#203

Post by inigyou »

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

    #define LEN 1000
    int tab[LEN];
    for (auto p = tab; p++; p
Not shown in frame: foo() calls exit(0) and tab always contains a 42.

The current standard allows the compiler to hoist unsafety only if there's no possibility of I/O or volatile memory access. This is the reason for the rule that infinite loops without the above are undefined behavior - it allows the compiler to merge two loops, the second of which might crash and the first of which can't be proven to terminate.

Re: Memory safety absolutists

#204

Post by Ygg2 »

inigyou wrote: post #147
Brian_K_White wrote: post #89

Earlier quoted context omitted.

There will always be one, so "it only takes one" is meaningless and invalid. That leaves less is better than more, and any form of less is as good as any other form of less.

Some Rust programs also had RCE CVEs.

Some is doing heavy misrepresentation.

Latest batch of LLM's Linux had 423 vulnerabilities. Out of which 10 were Rust*. Would you prefer more or less CVEs?

But it's like seat belt analogy. It's a helper not a panacea.

* Granted Rust isn't in the entire kernel yet. D

Re: Memory safety absolutists

#205

Post by inigyou »

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?

Haskell: newtype ShoeSize = ShoeSize Integer

(The first ShoeSize is the type name, the second is the name of the constructor that converts an integer to one, or pattern-matches on it. This is unambiguous in Haskell and they are often the same. It has symmetry with "data" which is for more general ADTs that can have more than one constructor.)

Re: Memory safety absolutists

#206

Post by inigyou »

Panzerschrek wrote: post #140
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…

Say I implement a dynamic array in the usual way with buffer, length, capacity. Currently the capacity is 50 and the length is 20. I access element 30 i.e. an unallocated element. Was that memory unsafe?

Re: Memory safety absolutists

#207

Post by inigyou »

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.

But if you're using Fil-C is it still a memory safety issue or just an ordinary crash bug?

Re: Memory safety absolutists

#208

Post by smj-edison »

tialaramex wrote: post #172
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…

Not familiar with the idea of "zapped", and I thought that Rust had a similar provenance model?

Working with pointers in Zig is much nicer, since

1. They're not nullable. If you want a nullable pointer, you would use `?*Object` instead of `*Object`.

2. They distinguish between single item and multi-item pointers. `*u8` is a pointer to a single u8, so I couldn't add to it or index it. `[*]u8` is a multi-item u8, which you can index.

3. Pointers track their alignment. I could make a pointer with `*align(128) Object` if I wanted to tag the bottom bits for example. Zig will require casts when changing alignment, for example casting from `*Object`.

4. Everyone uses slices when possible, pretty much Rust's slices.

5. A smaller detail, but there are sentinel pointers/slices, where you guarantee that the last item is a certain things. For example, a C string would be `[*:0]u8`, because it ends with 0.

Re: Memory safety absolutists

#209

Post by Pooge »

uecker wrote: post #178
inigyou wrote: post #175

Earlier quoted context omitted.

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)

> I can't remember a single incident where somebody I knew was directly affected by a memory safety issue

That doesn't mean the issue is nonexistent. See this article by Microsoft that shows the percentages of fixed CVEs that are related to memory safety.[1]

[1]: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...

Re: Memory safety absolutists

#210

Post by Hizonner »

If I want a memory-safe, garbage-collected language, I have a ton of choices already, and many of them are safer in other ways than either Rust or anything derived from C (richer type systems make programs safer). Not to mention being prettier and more ergonomic. The huge advantage of Rust is that it's memory-safe with no GC; it makes your timing and memory occupancy much more deterministic at those times when you have to care.
Post reply on HN