3 ms·
If this was merged into Rust, I assume it means the use of `unsafe` in std would be "pushed down" one level into Rustix instead. Wonder if that means it would
by algesten 5y ago
If this was merged into Rust, I assume it means the use of `unsafe` in std would be "pushed down" one level into Rustix instead.
Wonder if that means it would be easier to verify the correctness of `unsafe` use inside Rust itself?
- ansible 5y agoThe goal is to get this is merged into Rust's std library, they wouldn't write std on top of Rustix. > Wonder if that means it would be easier to verify the correctness of `unsafe` use inside Rust itself? If you mean usage of unsafe inside std (which the Rust compiler does depend upon), that is one of the explicit goals of Rustix. The usage of unsafe will be much more narrow overall, mostly surrounding the system calls themselves.
- algesten 5y agoYeah, that's what I mean. Sounds good!
- Arnavion 5y agoThe port of libstd linked in the article still uses rustix as a separate crate. In any case, I hope it remains separate. Third-party no_std code would benefit from it.
- ansible 5y agoI am under the impression that no-std code is primarily the concern of embedded systems that might not have much of an OS [1] at all, nevermind a suite of system calls to Linux. [1] Like a typical RTOS, that may provide some basic communication primitives, thread creation, and a hardware abstraction layer (HAL).
- roblabla 5y agoThat is nor necessarily the case. Embedded is a big user, but there are other reasons to use no_std, such as explicitly wanting to avoid heap allocations, or wanting greater control over the native APIs being called.
- sitkack 5y agoAlso Wasm support (can be viewed as a kind of embedded) and better portability. Anything that helps one separate the platform and more precisely define the platform boundary the better. Libc is necessary, but not good.