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

Improve on transmute for bindgen structs #10

Closed
ericseppanen opened this issue Apr 14, 2021 · 4 comments
Closed

Improve on transmute for bindgen structs #10

ericseppanen opened this issue Apr 14, 2021 · 4 comments

Comments

@ericseppanen
Copy link
Contributor

Is there a way to improve upon this?

    // Initialize an all-zeros ControlFileData struct
    pub fn new() -> ControlFileData {
        let controlfile: ControlFileData;

        let b = [0u8; SIZEOF_CONTROLDATA];
        controlfile = unsafe {
            std::mem::transmute::<[u8; SIZEOF_CONTROLDATA], ControlFileData>(b)
        };

        return controlfile;
    }
}

Ideally we could have some automatically derived functions that convert to/from [u8].

@ericseppanen
Copy link
Contributor Author

Rust-bindgen has an open issue on this.

Notes to refresh my memory in the future:

  • transmute into structs that are repr(C) are well-defined, so long as the members are also well-defined.
  • transmute into u8..u64 and i8..`i64' are well-defined (but malicious values can have weird side-effects).
  • transmute into floating-point values is well-defined, but might need to watch out for Signaling NaN values.
  • transmute into bool is undefined behavior if the source byte is not 0 or 1.
  • transmute into a fixed-size array is well-defined.
  • Everything else is probably undefined and dangerous.

@ericseppanen
Copy link
Contributor Author

The CheckPoint and ControlFileData structs contain bool members, and could be used to trigger undefined behavior if we use transmute.

:(

@lubennikovaav
Copy link
Contributor

Any ideas on how to do it correctly?
We can always serialize it manually, using get_u32_le() functions, as I did in the first version. The only problem I see with this approach is the need to write and support extra code.

@ericseppanen
Copy link
Contributor Author

I forgot that I had filed this. I think this conversation has moved to issue #6.

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

2 participants