Fix next_u64_via_fill to use little endian order

[dhardy]

See: #1011 (comment)

[vks]

A first step could be adding tests for next_u{32,64}_via_fill.

[dhardy]

These methods are only used twice: in OsRng (where it doesn't matter) and in ReadRng. The latter has this test (and a similar one for u64):

        let v = [0u8, 0, 0, 1, 0, 0, 0, 2, 0, 0, 0, 3];
        let mut rng = ReadRng::new(&v[..]);

        assert_eq!(rng.next_u32(), 1_u32.to_be());
        assert_eq!(rng.next_u32(), 2_u32.to_be());
        assert_eq!(rng.next_u32(), 3_u32.to_be());

Thus, currently on an LE platform the number if read in with only the most significant byte set, and the comparator gets a byte-swap. On BE, the number is read in with the least-significant byte set and the comparator does not get a byte-swap. Thus the tests pass but are wrong.

[dhardy]

Fixing this properly requires bumping the rand_core version. Are we planning on doing that before rand 0.8?

Alternatively we could just call it a bug-fix and note that basically no-one is affected (though we don't really know).

[josephlr]

Fixing this properly requires bumping the rand_core version. Are we planning on doing that before rand 0.8?

Alternatively we could just call it a bug-fix and note that basically no-one is affected (though we don't really know).

I think if we're doing rand_core v0.6 anyway (because of getrandom), then we should also just document this as using little endian and use to_le_bytes.

[dhardy]

Agreed, we should just fix this for v0.6.

[dhardy]

Okay, I'll try to get this done today.