You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -46,13 +46,13 @@ I do not intend to publish the crate on `crates.io`.
46
46
47
47
## Features
48
48
49
-
- `no_rand`: Allows to implement a fallback method to `getrandom` on unsupported targets
49
+
- `custom_rand`: Allows to implement a fallback method to `getrandom` on unsupported targets
50
50
51
51
## Bare metal
52
52
53
53
The crates partially supports `no_std` environments: it uses `Vec` a lot, so it relies on an external `alloc` crate. As each bit ciphered takes up a lot of space, storing ciphered objects on the stack wouldn't be possible (at least on low end machines). This is why the heap is needed here.
54
54
55
-
You may also need a source of randomness. On bare x86, randomness can still be retrieved using `RDRAND`. On other architectures, such as `aarch64-unknown-none`, you will have to implement `provide_getrandom`, which is a re-export of `getrandom::register_custom_getrandom`, gated behind the `no_rand` feature.
55
+
You may also need a source of randomness. On bare x86, randomness can still be retrieved using `RDRAND`. On other architectures, such as `aarch64-unknown-none`, you will have to implement `provide_getrandom`, which is a re-export of `getrandom::register_custom_getrandom`, gated behind the `custom_rand` feature.
0 commit comments