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

"Safe" Gecko binding sugars allow undefined behavior in safe Rust #15477

Open
mbrubeck opened this issue Feb 9, 2017 · 1 comment
Open

"Safe" Gecko binding sugars allow undefined behavior in safe Rust #15477

mbrubeck opened this issue Feb 9, 2017 · 1 comment
Labels

Comments

@mbrubeck
Copy link
Contributor

@mbrubeck mbrubeck commented Feb 9, 2017

The style::gecko_bindings::sugar module implements various safe methods and traits for FFI types from Gecko. However, many of these methods are actually unsafe because they depend on invariants that are not enforced. For example, this program has undefined behavior without using unsafe:

extern crate style;
use style::gecko_bindings::structs::nsTArray;

fn main() {
    let a = nsTArray { mBuffer: std::ptr::null_mut() };
    let b = &a[..];
}

Since the structs’ fields are public, we can’t statically enforce invariants on them. Assuming we don’t want to add runtime checks, we need to make sure these methods and impls can be used only on valid struct values. Possible solutions:

  • Create wrapper types that cannot be constructed in safe code, and implement methods/traits on the wrapper types instead of the original FFI structs.
  • Generate binding structs with private fields, and include the bindings and the impls in a single module.
  • Generate binding structs that use pub(super) or similar to make their fields public within some trusted supermodule, but private to outside code. Not yet possible in stable Rust (rust-lang/rust#32409).
@SimonSapin
Copy link
Member

@SimonSapin SimonSapin commented Feb 9, 2017

Generate binding structs that use pub(super) or similar to make their fields public within some trusted supermodule, but private to outside code

Another way to do this is to "flatten" that supermodule, use include!() inside of it without mod to have multiple files.

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

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.