Skip to content

milliseconds should be represented by u64, not u32 type #28171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kirillkh opened this issue Sep 2, 2015 · 3 comments
Closed

milliseconds should be represented by u64, not u32 type #28171

kirillkh opened this issue Sep 2, 2015 · 3 comments

Comments

@kirillkh
Copy link

kirillkh commented Sep 2, 2015

I found at least two cases in the standard API where milliseconds are represented by u32 variables:
std::sync::Condvar::wait_timeout_ms() and std::thread::park_timeout_ms(). However unlikely, it is not completely impossible for the user to expect being able to pass parameter value >= 2^32, as that value is less than 50 days. Also note that milliseconds are often passed on from another API that deals with u64 values, and so the user will likely convert the value unconditionally, without checking whether it's safe to do so.

@steveklabnik
Copy link
Member

/cc @rust-lang/libs

@kirillkh kirillkh changed the title milliseconds should be represented by u64, not u32 variables milliseconds should be represented by u64, not u32 type Sep 2, 2015
@nagisa
Copy link
Member

nagisa commented Sep 2, 2015

These functions are supposed to only be a compromise before we get stable Duration and Duration-taking functions, which is happening soon.

I doubt we will be doing a breaking change to them and might just deprecate them instead.

@alexcrichton
Copy link
Member

Ah yeah these are just going to be deprecated in favor of the Duration taking functions (which was the long-term plan since inception), so I'm gonna close this in favor #27771.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants