Hacker News Reader

Comment by cdoxsey | Hacker News Reader

In Go you can write unsafe code in libraries. You can even write raw assembly if you want.

We had an encoding library written in a very c-ish style for maximum performance, and sure enough, it had an off-by-one error on the last byte that could've been exploited.

It's funny that in severely limiting the area we could use unsafe we still somehow managed to write it improperly.

If anything it serves as a reminder of why memory safety is so critical and Rust was right to focus on it from the beginning... But developers always think they're the exception to the rule. I wonder how often 3rd party libraries end up using unsafe unnecessarily.

View on HN

Here's an example of a quite high profile Rust project discovered to have been (ab)using unsafe:

https://www.reddit.com/r/rust/comments/8s7gei/unsafe_rust_in...

... and, due to said awareness, the issues were all fixed. The presence of the unsafe keyword made the audit much easier. Everything is working as intended!

https://github.com/actix/actix-web/search?utf8=%E2%9C%93&q=u...

Good rust code doesn't have to be free of unsafe blocks. In some cases you can't avoid them, e.g. when doing memory mapping. Instead, the unsafe blocks semantically designate areas you should keep an eye on. I rather have 20 unsafe one-liners surrounded by safe wrappers in a project with several thousand LOC, than a 1k LOC C project where I have to take extra care with every step.

Sure. I haven’t looked at these exact blocks, but the point is that they were using tons of unsafe that they didn’t need to. Unsafe exists to be used, when it’s neccesary.

11 now? Iirc it was on the order of 100 before.

11 files, showing only the top two references per file. In a proper grep it shows about 35 unsafe references. Not bad indeed.

From that link:

>> Folks who are considering using actix-web might want to follow this thread about its heavy use of unsafe Rust.

It's one thing to make heavy use of a small bit of unsafe Rust. It's another to use unsafe heavily - like someone who just refuses to use the language properly and therefore just keeps writing unsafe code. It's not clear from the wording which case this was but they do say it was fixed, rather than declaring it an unmitigated disaster ;-)

> If anything it serves as a reminder of why memory safety is so critical and Rust was right to focus on it from the beginning

So why did they gave up on memory safety then and ditched their GC? Relying on alloca only has limited use cases, esp. with threads with their severe stack limits.

Rust did not give up on memory safety, nor does rust support alloca.

Isn't it a bit unfortunate that you have no idea about your own project.

Internally rust stack allocates most local objects, but it's size is unchecked. see eg. https://github.com/rust-lang/rust/issues/48055

2nd rust had memory safety in early 0.x releases with a proper GC, but it was removed. Now you either have to manually check local objects sizes or handle global refs manually or use unsafe and unhandled memory allocation for custom aggregates. The stdlib is full of such. nobody can declare memory safety for rust, only you, but unfortunately you exhausted your credibility long time ago. Also with your claim of concurrency safety ("then don't use mutexes"). rust is a fine languages, you don't need to lie about its properties. the docs need to remove false claims, and you seriously need to stop overhyping it.

Note that RFC is not implemented and not stable; this means it’s not in Rust.

If you can find memory unsafety in safe Rust, it would be a huge deal. Please file bugs. That doesn’t seem to be what you’re saying, though.

This issue outlines one of the problems with memory safety which is not fixed. Since you don't believe outsiders, look at your own tickets, where your own developers admit unsafety. There are probably more, this is just the first I found.

But the general problem is that rust cannot be made memory safe at all with its current architecture. Overlarge alloca calls are unsafe by default (either accept compile-time failures or accept run-time stack failures on new threads), and the strategy with global containers and references into it is unsafe. Even when rust would remove its unsafe keyword, and disallow malloc via ffi. Maybe you should fix your attitude towards your unsafeties.

I see no mention of memory safety or unsafety in the issue you linked. Could you be more specific?

I don't need to be more specific. Read the ticket outlining the alloca problems. It cannot get more safety relevant.

"Unresolved questions:

* [ ] How can we mitigate the risk of unintended unsized or large allocas? Note that the problem already exists today with large structs/arrays. A MIR lint against large/variable stack sizes would probably help users avoid these stack overflows. Do we want it in Clippy? rustc?

* [ ] How do we handle truely-unsized DSTs when we get them? They can theoretically be passed to functions, but they can never be put in temporaries."

That is a feature that is not yet implemented! Of course there may be unsolved questions.

Neither of those are memory safety relevant. (A stack overflow is a reliable crash, not memory corruption, in Rust.)

Reply on news.ycombinator.com