-
Notifications
You must be signed in to change notification settings - Fork 235
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
(c2rust-analyze
) Add known_fns!
for declaring the permissions on ptrs in known (i.e. libc
) UnknownDef
fn
s
#978
Conversation
… use in known (`libc`) `fn` permission annotations.
…tions on known (`libc`) `fn`s' ptrs.
…nst`-time so we don't need to `Box` `const`-known data.
…sent an permission-annotated type on a known `fn`.
…e number of perms match the number of ptrs in a type.
…nown (`libc`) `fn`s while also checking these definitions match `libc`'s.
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.
Looks good to me. It's a bit unfortunate that the annotations have to be written out-of-line (*mut *mut T: [A, B]
rather than *mut {A} *mut {B} T
or similar), but parsing the latter with macro_rules
would be a real pain. This should work fine for the libc use case, where the types can't get too complex.
Yeah, I agree that would be ideal, but that would be quite complex to parse and it'd probably mess up other nice-to-have stuff like syntax highlighting. |
cb5e3b2
to
5a64de9
Compare
…o platform specific things can be represented, such as Linux's `__errno_location` and macOS' `__error`.
5a64de9
to
24ce959
Compare
I wrote this as a
macro_rules!
macro so that we can write the pointer permission annotations inline with what the normalextern
declaration would look like. The macro checks that the declaration matcheslibc
's (or wherever it could be from) and that there are the correct number ofPermissionSet
s on each type corresponding to the number of pointers directly in that type (i.e., the number of*
).The syntax for this is an optional
: [PERM1a | PERM1b, PERM2a | PERM2b | PERM2c]
after each type in afn
signature, where the order of thePermissionSet
s corresponds to the pointers in the type in left-to-right order. For example:I'm still working on the integration of these
KnownFn
s intofn_sigs
asLFnSig
s, but I wanted to open a separate PR for how they are declared in the first place.