The following code, taken from a libstd test, sometimes panics in Miri, but only on Windows:
let now = Instant::now();
let earlier = now - Duration::SECOND;
It panics because on Miri, the value returned by QueryPerformanceCounter starts at 0 when the program starts. The function returns (via an out pointer) a signed integer. However, std casts that to an unsigned integer, and then subtracting from that can easily panic.
On Unix targets, signed integers are used, so there is no such problem.
It seems to me that either the test or the implementation in std is wrong.
- Either we don't allow computing
Instants from before program startup; then the test shouldn't subtract a whole second like that.
- Or we do allow that; then std should use
i64 instead of u64 to represent Instant on Windows.
A test like this has been present ever since the API existed, but it is not clear if that was meant as a guarantee or not.
My personal preference would be to resolve this by switching to i64; that seems like the most robust solution.
Cc @rust-lang/libs-api @ChrisDenton
The following code, taken from a libstd test, sometimes panics in Miri, but only on Windows:
It panics because on Miri, the value returned by
QueryPerformanceCounterstarts at 0 when the program starts. The function returns (via an out pointer) a signed integer. However, std casts that to an unsigned integer, and then subtracting from that can easily panic.On Unix targets, signed integers are used, so there is no such problem.
It seems to me that either the test or the implementation in std is wrong.
Instants from before program startup; then the test shouldn't subtract a whole second like that.i64instead ofu64to representInstanton Windows.A test like this has been present ever since the API existed, but it is not clear if that was meant as a guarantee or not.
My personal preference would be to resolve this by switching to
i64; that seems like the most robust solution.Cc @rust-lang/libs-api @ChrisDenton