a comment to get Twitter engagement from the 🦀 community
Conversation
Asking for pure curiosity. In C++ i guess he refers to implicit allocations done by copy operators etc. Which are not random but they could be hard to spot. Rust isn’t that bad in that aspect, with more explicit semantics for what is copied or moved. The only exception is drop
1
Rust's high-level standard library has a choice between APIs using panic (unwinding or abort) or reporting an error.
The low-level subset of the standard library doesn't provide dynamic allocation. If you're using that, then you can choose to only provide APIs reporting errors.
1
The proof of concept kernel Rust implementation doesn't use the high-level standard library. They used the liballoc library as a placeholder and that comes with both forms of methods (panic and error reporting). They explained they'll only be providing error reporting variants.
1
Unlike C, Rust has standard support for using it as a freestanding language and with a low-level subset of the standard library.
The language fully supports implementing the allocation APIs via the kernel allocators and only providing the variants of those APIs not using panic.
1
1
It is annoying that you lose all the standard dynamically allocated collections, etc. and need to fork the libraries if you don't want method variants panicking on OOM.
So, for example, you'd want Vec::push(x) to return Option<T> or Result<T, E> to get back `x` on alloc failure.
1
1
As a language, it fully supports it. It fits well into the idiomatic error handling system based on sum types (typically Result) including syntactic sugar for bubbling up the errors.
Unlike C++, no-unwind support is standard, but high level stdlib mostly relies on panic on OOM.
1
The high level stdlib has no relevance to the kernel usage because it MUST use $![no_std] (freestanding) code. The high-level stdlib (libstd) uses lower-level standard libraries (libcore, liballoc, etc.) and they can use some of those, but they will need a stripped down liballoc.
1
So, basically, the only issue is they haven't yet forked liballoc to delete the methods doing panic on OOM. It's the same reason they need other placeholder stubs doing panic to fill in APIs used by stdlib code they've included via libcore, etc. Could fork libcore and delete it.
2
I guess libcore includes functionality for working with u128/i128 and that depends on certain compiler-rt software fallbacks, etc. which rather than implementing they stubbed out. They either just need to use compiler-rt, make real implementations, or fork libcore to delete that.
You could happily use the same stuff in libcore causing that issue via GCC and Clang extensions.
If the architecture doesn't have a built-in compiler implementation, it calls out to compiler-rt functions that are partially missing in the kernel and you get a link error.