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

Investigate typelayout as a safer alternative to plain #403

Open
roblabla opened this issue Aug 6, 2019 · 0 comments
Open

Investigate typelayout as a safer alternative to plain #403

roblabla opened this issue Aug 6, 2019 · 0 comments
Labels
safety Something is unsound, could be unsafe type-feature New feature or request

Comments

@roblabla
Copy link
Member

roblabla commented Aug 6, 2019

Currently, we use plain as a way to do safe cast from byte slices to POD types (which we do in a few places). There is a problem with plain however: We need to manually unsafe impl Plain for Type {}, and when doing so, we need to manually check that the invariants are upheld (especially regarding the absence of padding bytes).

Enter typelayout. It's a bit of a crazy crate that will implement a few traits on types if their layout follow certain rules (such as NoPadding being present only if the crate has no padding bits). It does so by leveraging frunk, another crazy crate that, with the help of a derive macro, allows getting information on a type's layout.

I would like to try removing all usage of plain and replacing it with typelayout, as it would allow us to automatically ensure all the invariants are being upheld. However, we need to make sure we don't take a huge compile-time hit, as frunk could possibly be a bit heavy. Needs some checking.

@roblabla roblabla added type-feature New feature or request safety Something is unsound, could be unsafe labels Aug 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
safety Something is unsound, could be unsafe type-feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant