-
Notifications
You must be signed in to change notification settings - Fork 47
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
Add some missing FFI safe types #42
base: master
Are you sure you want to change the base?
Conversation
These additional types have representations that are defined to be the same as some underlying FFI safe representation.
compatible to a `*const T` and `*mut T` pointer; | ||
- `core::num::NonZero*`, then is compatible to the corresponding integral | ||
primitive type; | ||
- a `repr(transparent)`-annotated `struct` with only one field, where that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're allowed to have more than one field if one is a align-1 ZST. This is common for PhantomData, for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're even allowed to have an arbitrary amount of align-1 ZSTs, however this seemed very similar to the ZST restrictions below. The list style itself is not exactly exhaustive in either case. I have not yet seen any such use in ffi in the wild whereas I did find use for all other cases that I've listed.
Translation of pull request ANSSI-FR#42
Translation of pull request ANSSI-FR#42
Translation of pull request ANSSI-FR#42
Translation of pull request ANSSI-FR#42
- pointers, | ||
- an `Option<T>` where `T` is either | ||
- `core::ptr::NonNull<U>` and `U` is a `Sized` C-compatible type, then it is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The part with the pointers (such as *mut U
) forget to express the U
is a Sized
... invariant that Option<ptr::NonNull<U>>
do.
I'd weaken the C-compatible bound on U
, but explicit the Sized
requirement:
- pointers, | |
- an `Option<T>` where `T` is either | |
- `core::ptr::NonNull<U>` and `U` is a `Sized` C-compatible type, then it is | |
- pointers to some type `Pointee`, where: | |
- `Pointee : Sized`, | |
- `Pointee` is either a C-compatible type too (and only then can the pointer be dereferenced by the C side), or it is not, in which case it must be treated as a pointer to an opaque object (_c.f._, the dedicated section \[FIXME:add link\]). | |
- an `Option<T>` where `T` is either | |
- `core::ptr::NonNull<Pointee>` where `Pointee` meets the constraints mentioned for the pointer case. |
These additional types have representations that are defined to be the
same as some underlying FFI safe representation.