urandom.randint handling of >32bit values on 64-bit arch
Noticed this while looking at https://github.com/micropython/micropython/issues/6712
>>> random.randint(0, 2**32)
0
>>> random.randint(0, 2**32-1)
(hangs)
On 32-bit platforms, both these examples would fail to convert the second argument to a small int (which I think is the correct behaviour for MicroPython).
On 64-bit though, they're valid small integers, but then there's an implicit conversion to uint32_t in yasmarang_randbelow.
I guess either we could use a 64-bit Yasmarang on 64-bit arch? Or add another check?
randint() returns machine word instead of an actual int object.
Micropython is more than happy to let 2**128 return a python int object but for randint(2**33,2**33-1) Micropython will attempt to clamp that range down to a 32bit number and warn of an overflow if the value is more than 32bits in size. This behavior is not inline with the rest of the arithmetic options of the environment. For some reason the randint function and the getrandbits function both attempt to clamp it down to a 32bit value.
This makes no sense as I can very easily have very large ints elsewhere in the functions. This kind of "half-in" "half-out" behavior makes no sense. It's also no listed anywhere in the documentation about this strange behavior. The pow function just operating on floating point numbers is fine as there's an easy workaround within the language itself but randint trying to clamp down to a machine word instead of just returning an int object is beyond me.