Integration into std #21

Activity

1. tarcieri commented on May 21, 2019

   

   tarcieri

   on May 21, 2019

   Contributor

   More actions

   I think it'd be nice to have something that no_std users can also leverage (even if gated behind a nightly-only feature flag), although that might be out-of-scope for this particular RFC.

   "Isn't that what the rand crate is for?" you might ask? Well I'm thinking something a little global_allocator perhaps. Here's a handwavy example:

   // If this seems too hard to stabilize, feature gate it?
   #[feature(global_rng)]
   
   #[global_rng]
   pub fn getrandom_inner(dest: &mut [u8]) -> Result<(), Error> {
       [...]
   }

   The idea being that embedded packages can plug in a proprietary global RNG.

   I'd love to use getrandom for cryptography projects, but there needs to be a way for these projects to support no_std. I've started switching to getrandom on my std-dependent projects, but I'm hesitant to do so on my projects which support no_std for these reasons.

   👍React with 👍1Reacted by ryan
2. dhardy commented on May 21, 2019

   

   dhardy

   on May 21, 2019

   MemberAuthor

   More actions

   If getrandom remains as a crate, this isn't too hard: I proposed a couple of solutions in #4.

   On the other hand, if this were integrated into the standard library, it would need to be included in core as a wrapper around some inner function like you listed. I'm not really sure how much sense this makes and don't have much interest in pushing for integration myself.

   (Note: in both cases, another crate implementing some kind of entropy pool may be needed to implement getrandom_inner with the limited functionality available on some platforms.)
3. newpavlov commented on May 21, 2019

   

   newpavlov

   on May 21, 2019

   Member

   More actions

   IIUC with inclusion into core we will not need a separate inner function. getrandom function can be a weak lang item (akin global allocator), which will have an always erroring default implementation overwritable by applications.

   I think it will be reasonable to first start with #4 and move with std inclusion RFC later.

   👍React with 👍1Reacted by Tony Arcieri
4. tarcieri commented on May 21, 2019

   

   tarcieri

   on May 21, 2019

   Contributor

   More actions

   @newpavlov yeah, something to the effect of a lang item was exactly what I was thinking, but I'm not really aware of the difficulty involved in adding a new one, and I know a lot of people think there are too many already
5. newpavlov commented on Dec 14, 2020

   

   newpavlov

   on Dec 14, 2020

   Member

   More actions

   Closing in favor of rust-lang/rust#62079.
6. newpavlov

   closed this as completedon Dec 14, 2020