4 ms·

> For Compatibility with no_std tgts, e.g. embedded, Use the no_std feature. Note, this is not the recommended way to use Rust feature flags. They are additive

> For Compatibility with no_std tgts, e.g. embedded, Use the no_std feature. Note, this is not the recommended way to use Rust feature flags. They are additive and so the correct way to make a `no_std` compatible crate is to have a `std` feature flag that conditionally enables use of the `std` library. Referring to Effective Rust: > Note that there's a trap for the unwary here: don't have a no_std feature that disables functionality requiring std (or a no_alloc feature similarly). As explained in Item 26, features need to be additive, and there's no way to combine two users of the crate where one configures no_std and one doesn't—the former will trigger the removal of code that the latter relies on. - https://www.lurklurk.org/effective-rust/no-std.html https://www.lurklurk.org/effective-rust/no-std.html

deleted 2y ago
[deleted]
leoedin 2y ago
I'm a bit confused by this. In practice you can't combine no_std and std within a single project anyway - because then the entire app is relying on the std library, so is no longer no_std. Surely if a user sets no_std as a feature, they expect that to be the case for the entire application?
- junon 2y ago
  std is based on core, the latter of which is available in no_std. Std is thus additive. GP comment is correct; this is how the entire ecosystem structures no_std-compatible crates.
- sapiogram 2y ago
  > In practice you can't combine no_std and std within a single project anyway You can with Rust features. It allows a library to conditionally compile certain parts of the code, and users of the library can decide which features to enable. If a library only uses stdlib in code gated by #[feature(std)], users can disable that flag, and use the library in no_std contexts.
  - endofreach 2y ago
    Interesting. I have no rust experience yet, so i wonder: while that sounds very cool, how does it look like in the wild? To me it seems like this could quickly turn into a nightmare, if the code is not very well organized / structured. In reality shouldn't this rather be two separate libs? But maybe i should first learn rust before asking.
    - the__alchemist 2y ago
      Anecdotally, the use cases I've had are all clearly in one category or the other: I'm either building firmware for an embedded device, or building a PC application. I'm curious about the overlap cases.
      - mlsu 2y ago
        I’ve used it in the past for creating a shared messaging crate that has packet definitions, handshake logic, serialization/deserialization. I think with sloppy/complex code it could start to resemble #ifdef PLATFORM complexity if you do a lot inline, but cargo workspaces are a good way to reduce the blast radius.
      - gibibit 2y ago
        You're right that an application project (a `binary crate` in Rust parlance) for embedded firmware versus a PC application is very different. But library crates are often usable in both an embedded or system-level context or in a full-fledged desktop GUI application. Consider these common libraries you might use in either a `std` project (PC application, web microservice) or `no_std` project (embedded microcontroller firmware, bootloader, Linux kernel module, blockchain smart contract): - data encoding (https://crates.io/crates/base64 https://crates.io/crates/base64 for instance), - hashing (SHA2 https://github.com/RustCrypto/hashes/tree/master/sha2 https://github.com/RustCrypto/hashes/tree/master/sha2), - data structures (https://github.com/Lokathor/tinyvec https://github.com/Lokathor/tinyvec) - time/date manipulation (https://docs.rs/chrono/latest/chrono/ https://docs.rs/chrono/latest/chrono/)
- LoganDark 2y ago
  > In practice you can't combine no_std and std within a single project anyway This is not in any way the problem. The reason for having std be the feature instead of having no_std be the feature is because if a dependency unsets the default features because it does not rely on the std feature and then someone else still does rely on the std feature then everything will still work properly. If no_std is the feature then if a dependency sets the no_std feature because it does not rely on the std features and then someone else does not set no_std because they do rely on the std features then there will be problems because there won't be any ability for the someone else to unset the no_std feature that was specified by the first dependency.
the__alchemist 2y ago
This is great info! I tried using that approach, but had trouble enabling the `num_traits/libm` dependency on no_std only. Does anyone know if that's possible?

deleted 2y ago

[deleted]

leoedin 2y ago

I'm a bit confused by this. In practice you can't combine no_std and std within a single project anyway - because then the entire app is relying on the std library, so is no longer no_std. Surely if a user sets no_std as a feature, they expect that to be the case for the entire application?

junon 2y ago
std is based on core, the latter of which is available in no_std. Std is thus additive. GP comment is correct; this is how the entire ecosystem structures no_std-compatible crates.
sapiogram 2y ago
> In practice you can't combine no_std and std within a single project anyway You can with Rust features. It allows a library to conditionally compile certain parts of the code, and users of the library can decide which features to enable. If a library only uses stdlib in code gated by #[feature(std)], users can disable that flag, and use the library in no_std contexts.
- endofreach 2y ago
  Interesting. I have no rust experience yet, so i wonder: while that sounds very cool, how does it look like in the wild? To me it seems like this could quickly turn into a nightmare, if the code is not very well organized / structured. In reality shouldn't this rather be two separate libs? But maybe i should first learn rust before asking.
  - the__alchemist 2y ago
    Anecdotally, the use cases I've had are all clearly in one category or the other: I'm either building firmware for an embedded device, or building a PC application. I'm curious about the overlap cases.
    - mlsu 2y ago
      I’ve used it in the past for creating a shared messaging crate that has packet definitions, handshake logic, serialization/deserialization. I think with sloppy/complex code it could start to resemble #ifdef PLATFORM complexity if you do a lot inline, but cargo workspaces are a good way to reduce the blast radius.
    - gibibit 2y ago
      You're right that an application project (a `binary crate` in Rust parlance) for embedded firmware versus a PC application is very different. But library crates are often usable in both an embedded or system-level context or in a full-fledged desktop GUI application. Consider these common libraries you might use in either a `std` project (PC application, web microservice) or `no_std` project (embedded microcontroller firmware, bootloader, Linux kernel module, blockchain smart contract): - data encoding (https://crates.io/crates/base64 https://crates.io/crates/base64 for instance), - hashing (SHA2 https://github.com/RustCrypto/hashes/tree/master/sha2 https://github.com/RustCrypto/hashes/tree/master/sha2), - data structures (https://github.com/Lokathor/tinyvec https://github.com/Lokathor/tinyvec) - time/date manipulation (https://docs.rs/chrono/latest/chrono/ https://docs.rs/chrono/latest/chrono/)
LoganDark 2y ago
> In practice you can't combine no_std and std within a single project anyway This is not in any way the problem. The reason for having std be the feature instead of having no_std be the feature is because if a dependency unsets the default features because it does not rely on the std feature and then someone else still does rely on the std feature then everything will still work properly. If no_std is the feature then if a dependency sets the no_std feature because it does not rely on the std features and then someone else does not set no_std because they do rely on the std features then there will be problems because there won't be any ability for the someone else to unset the no_std feature that was specified by the first dependency.

the__alchemist 2y ago

This is great info! I tried using that approach, but had trouble enabling the `num_traits/libm` dependency on no_std only. Does anyone know if that's possible?