bugfixes in Libc.rand for Windows

[stevengj]

Fixes a bug noted by @mschauer in #32894 (comment), which seems to originate in #24874 by @rfourquet, where the code used a / 2^32 expression that overflows on 32-bit machines. This PR uses * 2.0^-32 instead, which constant folds and is exact in Float64.

Also fixes another problem in the same code on Windows — the code assumed that RAND_MAX is at least 2^16-1, which seems to be true on supported Unix systems (GNU and BSD), but on Windows it is 2^15-1 so we need a third rand call to get 32 bits of randomness (or "randomness").

[JeffBezanson]

Use ldexp?

[stevengj]

@code_native g(UInt32(3)) reports an enormous amount of code for g(x) = ldexp(Float64(x), -32) for some reason…

(ldexp(x, n) only currently supports floating-point x.)

[stevengj]

I think ldexp is probably slower here here because it doesn't seem to constant-propagate the exponent?

[stevengj]

Note that Libc.rand seems to be currently unused in Base — it's only use in mktempdir was removed in #31230.

[rfourquet]

Note that Libc.rand seems to be currently unused in Base — it's only use in mktempdir was removed in #31230.

Indeed a call to Libc.rand in mktempdir was replaced by a call to Base.rand in tempname. IIRC, I wrote Libc.rand in a PR before it was decided to keep rand in Base when Random was put in stdlib, but Libc.rand seemed useful to me in case Base needs to become more independant from stdlib modules.

[stevengj]

Test failure seems unrelated?

[PallHaraldsson]

This is so strange! Windows (libC there) still is struck in 16-bit world (for compatibility with old code, why not other platforms?)? So Libc.rand(Int) is non-portable, "affecting" Julia too, with the different RAND_MAX depending on platforms?

Note that Libc.rand seems to be currently unused in Base

I'm not sure who actually uses it outside of the standard library, but shouldn't Libc.rand just be deprecated, at least less precise Libc.rand(Float64)? Other problems there, e.g. "twice" docs is outdated for Windows:

# To limit dependency on rand functionality implemented in the Random module,
# Libc.rand is used in file.jl, and could be used in error.jl (but it breaks a test)
"""

[..] for non-Windows: why not take advantage of larger Base.rand(UInt32) not needing to call rand twice?

    rand(::Type{UInt32}) = ((rand() % UInt32) << 16) ⊻ (rand() % UInt32)

rand(::Type{Float64}) = rand(UInt32) * 2.0^-32  # seems wrong, Float64 has 53 bits of precision, ok to backport fix with more?

[stevengj]

Okay to merge?