Do you think that no_std category/tag should be for crates targetting no_std or for things which can be ran/built with no_std?
Inspired from this request: Various fixes to allow testing with `no_std` by pitdicker · Pull Request #1177 · chronotope/chrono · GitHub
no-std
Crates that are able to function without the Rust standard library.
So would you disagree with djc's comment from: issue various fixes...
Thats great! Do you think it should be added to the no_std category on crates.io? Might be a big feather in the crates cap.
It doesn't seem especially important. In my mind the category is for crates that particularly target no_std environment, not for every crate that can be built without
std.
I guess not. If I understood them correctly, what they're saying is, that e.g. chrono can be built with limited functionality for no_std by disabling the default features.
Therefore, chrono in its entirety does not function without the Rust standard library, only parts of it. Hence, I'd not put it into the no-std category, if I were the maintainer.
That makes sense, thank you!
Some hardware don't have machinery like memory management units, or atomic operations that support day-to-day work of a mainstream OS like Linux and Windows. Default memory allocator in Rust (let's call it alligator) assumes there's an OS up there with an MMU at its disposal for example. This might cause code written with this allocator to stop working on the MMU-less hardware.
What we do with no_std is telling the compiler, we don't expect any service from an OS and if an allocation is needed we can use a specialized allocator (let's call it irrigator) to handle dynamic memory without an OS. Else we just go full stack. Which is not a bad idea in embedded.
This question is about using the no_std tag on crates.io, not about the attribute.
I know. But if anyone searches for this thread for "What is no_std?" part, they can at least find some info.
I'll be honest, I have some difficulty discovering whether libraries are no_std compatible if it is not explicitly announced somewhere. If the only way to find out whether a crate can be used in my environment is by grepping for "no_std" or inferring support from feature flags [1], I am less likely to consider using it. And I'm hopelessly lost when it comes to trying to find libraries that may be suitable.
chrono is an example of one that I would have never imagined is capable of running (even in limited form) on bare metal with no OS support. It might have dawned on me if there was some kind of getclock/chrono split like there is a getrandom/rand split [2]. But as far as I am aware, there is no one-size-fits-all library to get the system clock independently of handling time.
I don't know if the no-std category slug is the right way to address discoverability, but it is awesome when it works. And the slug's description strongly implies that this is the intent.
This is the same issue I am having, maybe a new category called no_std_compat which can be set if it is possible to use either a portion or the whole crate on no_std even if it doesn't target or fully support no_std. Having a list of things that take some TLC to use but might be very useful on bare metal would be a godsend for my use case.
I think this can be covered by searching for crates with "alloc" or "std" features without a new tag or category. But I think there is no search mask for it (I did not find one).
This is precisely the problem, and the no-std and no-std::no-alloc slugs appear to be the solution. It requires maintainer buy-in to adopt.
The lib.rs top-level no-std page includes both crates tagged with no-std and crates autodetected by having a #![no_std] in src/lib.rs. (Documentation)
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.