(c2rust-analyze) Add almost all libc KnownFns used in lighttpd_rust_amalgamated
#998
Conversation
…:STRING_LITERAL` (cleaner).
…gamated` to `all_known_fns`, un-annotated. There are a lot of `fn`s, so this just adds them unannotated so far. Since `known_fns!` checks the number of perms matches the number of pointers, new `fn`s with pointers are commented out for now. A few `libc` `fn` names are included as comments as they are for some reason not in Rust's `libc` crate, but are a part of `libc`. The other foreign `fn`s in `lighttpd_rust_amalgamated` are `pcre2` `fn`s, not `libc` ones.
…ed for args vs. returns for `KnownFn`s.
…FnTy` has no perms.
…ble, with a few exceptions: * Return types that are declared as `*mut` but are not supposed to be written as they may be in statically allocated memory that will be overwritten. * Vararg `fn`s. * `libc` `fn`s that are not in the `libc` crate for some reason. * `fn`s with `fn` ptr args. * Non-`libc` `fn`s used by `lighttpd_rust_amalgamated` (`pcre2` `fn`s).
… statically allocated memory that aren't meant to be modified, mark them as `READ`, not `READ | WRITE`. They are also commented as such.
…he `libc` crate with `TODO`s.
| fn calloc( | ||
| nobj: size_t, | ||
| size: size_t, | ||
| ) -> *mut c_void: [READ | WRITE | OFFSET_ADD | FREE]; |
There was a problem hiding this comment.
I think the return type here should actually have OFFSET_SUB in addition to OFFSET_ADD. It's legal and reasonable to do things like calloc(...).offset(1).offset(-1), and it seems difficult to specify something like "you can do OFFSET_SUB on this pointer, but only if you do an OFFSET_ADD first".
(Though really calloc should probably be special-cased along with malloc, realloc, etc at some point.)
String arguments should stick with just OFFSET_ADD to be more permissive (the details of OFFSET_ADD vs OFFSET_SUB vs both doesn't matter here anyway, since it's all the same once it's been cast to a raw pointer). Returned strings and arrays should also get OFFSET_SUB, though.
There was a problem hiding this comment.
I think the return type here should actually have
OFFSET_SUBin addition toOFFSET_ADD. It's legal and reasonable to do things likecalloc(...).offset(1).offset(-1), and it seems difficult to specify something like "you can doOFFSET_SUBon this pointer, but only if you do anOFFSET_ADDfirst".
Why couldn't we have something like this for offset?
fn offset<T>(self: *const T: [OFFSET_ADD], count: isize) -> *const T: [OFFSET_ADD | OFFSET_SUB];(Though really
callocshould probably be special-cased along withmalloc,realloc, etc at some point.)
I think it already is. I just added all of the libc fns used by lighttpd_rust_amalgamated for consistency, even if they are already builtins.
There was a problem hiding this comment.
In dc4c467, I made the fns that internally do .offsets return OFFSET_SUB, which I think is clearly correct (e.x. for strchr). I'm still not sure about the others, though. From what I understood, if I pointer has only OFFSET_ADD, it can be made into a slice. But if it has OFFSET_SUB, too, then it can't become a slice. When a fn returns a pointer to the beginning of memory that could be a slice, why would we add OFFSET_SUB?
…tter explanation.
…y say `VALID` for future greppability if/when we add `PermissionSet::VALID`.
c2rust-analyze) Hardcode ptr permissions and effects of knownstdandlibcfunctions #865.This adds
known_fns!annotations for alllibcfns used inlighttpd_rust_amalgamatedwith a few exceptions:fns aren't yet supported (support for some of them is a WIP)libcfns that are not in thelibccrate for some reason (will find them)fns withfnptr args, as I'm not certain how to handle them yetlibcfns used bylighttpd_rust_amalgamated(pcre2fns)I've left
TODOs for these, as well as for some other ptr perms I wasn't certain about and would like to have reviewed.I've also outlined in #865 (comment) how we might support some of these exceptions.