Document implementation of ring::rand::SystemRandom::fill() better.

src/rand.rs

@@ -55,12 +55,6 @@ pub trait SecureRandom {
 /// `fill()` once at a non-latency-sensitive time to minimize latency for
 /// future calls.
 ///
-/// On non-Linux Unix-/Posix-ish platforms, `fill()` is currently always
-/// implemented by reading from `/dev/urandom`. (This is something that should
-/// be improved, at least for platforms that offer something better.)
-///
-/// On Redox, `fill()` is implemented by reading from `rand:`.
-///
 /// On Linux, `fill()` will use the [`getrandom`] syscall. If the kernel is too
 /// old to support `getrandom` then by default `fill()` falls back to reading
 /// from `/dev/urandom`. This decision is made the first time `fill`
@@ -69,9 +63,17 @@ pub trait SecureRandom {
 /// target system is known to support `getrandom`. Library crates should avoid
 /// explicitly enabling the `dev_urandom_fallback` feature.
 ///
+/// On macOS and iOS, `fill()` is implemented using `SecRandomCopyBytes`.
+///
+/// On Redox, `fill()` is implemented by reading from `rand:`.
+///
 /// On Windows, `fill` is implemented using the platform's API for secure
 /// random number generation.
 ///
+/// Otherwise, `fill()` is implemented by reading from `/dev/urandom`. (This is
+/// something that should be improved for any platform that adds something
+/// better.)
+///
 /// When `/dev/urandom` is used, a file handle for `/dev/urandom` won't be
 /// opened until `fill` is called. In particular, `SystemRandom::new()` will
 /// not open `/dev/urandom` or do other potentially-high-latency things. The