Hi, does anyone here use no_std binaries for targets with a full std? I'd love to hear about how no_std is being used outside of minimal embedded targets, where you have a well supported (by rust) OS and a specific C runtime environment. E.g. you're using x86_64-unknown-linux-gnu, x86_64-pc-windows-msvc or aarch64-apple-darwin but compile a binary using #![no_std] anyway.
2 Likes
One obvious use case is to test that the code works in #![no_std] environment. I'm developing on a T1 target, so of course I do any tests and experiments on it as well.
3 Likes
Rust-For-Linux replaces std and alloc with its own non-aborting implementations.
2 Likes
Rust-for-Linux uses no_std kernel targets (like *-unknown-none), and they're actually moving away from their alloc fork in the near future too (but still setting --cfg no_global_oom_handling).
3 Likes
We have several use-cases to avoid std on tier1, but they all boil down to avoiding the runtime it enforces (e.g., it installs ELF-ctors for argv capture).
For instance, we build custom ELF runtimes, ELF relocators, and dynamic linkers in pure Rust. For those we use no_std. Additionally, we have efforts to build strict capability-based runtimes, and these conflict with the global state std enforces.
The CloudABI project was a similar effort, but got discontinued.
3 Likes
This is explicitly a hobby/learning usage, but I have a toy binary built on x86_64-pc-windows-msvc which uses #![no_std] for the purpose of implementing its own alloc/std functionality directly on top of win32 API. It exists for scratching my "implement your own runtime" itch, and even has a partial #![no_core] version. (It's called notstd/notcore :smile:)
2 Likes
One thing that came up on Windows is that using std automatically adds >100kb to the binary size mainly due to panic+backtrace+fmt. This matters for people wanting particularly small binaries.
3 Likes
Can you say more about the situations in which those extra bytes are deal-breakers for running on Windows? A fixed cost like that doesn't seem like that big a deal compared to the *checks* 30,471,408,390 bytes that my c:\Windows folder is using -- it's not like you run x86_64-pc-windows-msvc on something with storage measured in MB.
. I'll see if anyone is willing to say more. It's definitely something that's come up a few times now.
I doubt the on-disk storage size is the issue though. And there are situations where your Windows will be much smaller than a desktop install (e.g. nanoserver).