QUERY · ISSUE

urandom.randint handling of >32bit values on 64-bit arch

openby jimmoopened 2020-12-22updated 2021-05-30

bugextmod

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?

CANDIDATE · PULL REQUEST

Fix compilation warnings for Windows 64 bits

mergedby srinsozopened 2024-01-30updated 2024-02-15

extmod

Here is some missing cast and other minor change that prevent compilation warning if mp_int_t is defined as integer 64 bits.

Assessment

Q Qwen · high

Both items involve 64-bit integer handling in extmod/modrandom.c, specifically in yasmarang_randbelow and mod_random_randint. However, the query reports a runtime behavioral bug (returns 0 or hangs for values >=2^32 due to implicit uint32_t truncation), while the candidate PR only adds type casts to suppress compilation warnings from 64-bit type mismatches. Adding casts to silence warnings does not fix the underlying algorithmic problem — the PRNG still operates on uint32_t internally, so values >32 bits will still be incorrectly handled at runtime. The candidate touches the same code but does not resolve the query's reported bug.

Suggested action

Reference PR #13556 as context when fixing issue #6718, but treat the issue as still open. The actual fix requires either a 64-bit Yasmarang implementation or an explicit range check in randint/randrange to reject arguments exceeding uint32_t max on 64-bit platforms.

urandom.randint handling of >32bit values on 64-bit arch

Fix compilation warnings for Windows 64 bits

Keyboard