Skip to content
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

time::Instant is a different size of different platforms #43332

Closed
Thomasdezeeuw opened this issue Jul 19, 2017 · 8 comments
Closed

time::Instant is a different size of different platforms #43332

Thomasdezeeuw opened this issue Jul 19, 2017 · 8 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Thomasdezeeuw
Copy link
Contributor

time::Instant on Linux is 16 bytes, while it is 8 bytes on MacOs. This makes it hard to assert the size of any structs using it.

Playground link

use std::mem;
use std::time::Instant;

fn assert_size<T>(want: usize) {
    assert_eq!(mem::size_of::<T>(), want);
}

fn main() {
    // This is 16 on Linux, but 8 on MacOS (and Windows?).
    assert_size::<Instant>(16);

    // This is 24 on Linux, but 16 on MacOS (and Windows?).
    assert_size::<Option<Instant>>(24);
}
@sfackler
Copy link
Member

Why do you want to make assertions about the size of a struct with an Instant in it?

@Mark-Simulacrum Mark-Simulacrum added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jul 19, 2017
@Thomasdezeeuw
Copy link
Contributor Author

Thomasdezeeuw commented Jul 19, 2017 via email

@Mark-Simulacrum
Copy link
Member

Perhaps you could use #[cfg(unix)]? I don't think it's likely that we'll change anything to increase or decrease the size of Instant based on platform... On OS X today, an Instant is defined by u64 whereas on other unix platforms it's a libc::timespec... I would presume that this is correct and won't change.

@Thomasdezeeuw
Copy link
Contributor Author

Thomasdezeeuw commented Jul 19, 2017 via email

@Mark-Simulacrum
Copy link
Member

Hm, well, I'll nominate for libs team, but I personally don't think documenting differences in size really makes sense today.

@durka
Copy link
Contributor

durka commented Jul 19, 2017

@Mark-Simulacrum stuff like this could be a good candidate for the "portability lint" discussed here and here.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 28, 2017
@alexcrichton
Copy link
Member

The libs team decided that we're not going to make any guarantees about sizes of structs, and we've opened #43601 to track documenting that the sizes may be different.

@Thomasdezeeuw
Copy link
Contributor Author

Sounds good to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants