7 ms·

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

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.

jack1243star 8y ago
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_actixweb_other_libraries/ https://www.reddit.com/r/rust/comments/8s7gei/unsafe_rust_in...
- steveklabnik 8y ago
  ... 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!
  - HugoDaniel 8y ago
    https://github.com/actix/actix-web/search?utf8=%E2%9C%93&q=unsafe&type= https://github.com/actix/actix-web/search?utf8=%E2%9C%93&q=u...
    - Nimelrian 8y ago
      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.
    - steveklabnik 8y ago
      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.
      - HugoDaniel 8y ago
        11 files, showing only the top two references per file. In a proper grep it shows about 35 unsafe references. Not bad indeed.
- phkahler 8y ago
  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 ;-)
rurban 8y ago
> 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.
- steveklabnik 8y ago
  Rust did not give up on memory safety, nor does rust support alloca.
  - rurban 8y ago
    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 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.
    - steveklabnik 8y ago
      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.
      - rurban 8y ago
        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.

jack1243star 8y ago

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_actixweb_other_libraries/ https://www.reddit.com/r/rust/comments/8s7gei/unsafe_rust_in...

steveklabnik 8y ago
... 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!
- HugoDaniel 8y ago
  https://github.com/actix/actix-web/search?utf8=%E2%9C%93&q=unsafe&type= https://github.com/actix/actix-web/search?utf8=%E2%9C%93&q=u...
  - Nimelrian 8y ago
    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.
  - steveklabnik 8y ago
    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.
    - HugoDaniel 8y ago
      11 files, showing only the top two references per file. In a proper grep it shows about 35 unsafe references. Not bad indeed.
phkahler 8y ago
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 ;-)

rurban 8y ago

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

steveklabnik 8y ago
Rust did not give up on memory safety, nor does rust support alloca.
- rurban 8y ago
  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 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.
  - steveklabnik 8y ago
    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.
    - rurban 8y ago
      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.