mirrors/arti.git/crates/arti-rpc-client-core/src/ffi.rs, branch arti-v1.2.6mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.62024-07-31T17:54:16Zffi: Add some explicit ()s to prove they are there.2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-31T17:25:29Zurn:sha1:c4f8b574cfe7c35db3cc074fec59937b051b9c93ffi: Document safety for each function using ffi_body_raw.2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-31T13:00:04Zurn:sha1:6961e83f6ecbd975d7ed3610d6170a76240cac1affi: rename ffi_body_simple to ffi_body_raw2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-31T12:50:29Zurn:sha1:5cdfa510127ea53126b1398f44e26b2fd540326fffi: use void to omit unreachable "on invalid" blocks2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-30T21:06:30Zurn:sha1:9c4c9e72d4cc76d58c577d15dbaea67507b108f3ffi: Remove all non-opt conversions2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-30T20:40:22Zurn:sha1:fa70f79c0b2e930077896272dde44a2e15a989fa
Additionally, inline the related conversion functions.
This should reduce the total amount of unsafe code that somebody
would need to look at.
ffi: Always abort on panic.2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-29T17:36:19Zurn:sha1:a968848d576f5bf9ae0a1624ff1bd07d01060e14Use macros to make FFI functions simpler to read and check.2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-25T22:55:53Zurn:sha1:3303533551c63ab2e41b3790e402767e928983c9
These macros do the only part of our FFI functions that needs to be
`unsafe`: converting input pointers into types that can be used in
safe rust. I've added documentation about what requirements each of
these conversions puts onto out inputs: both informally, and via a
reference to the relevant parts of the Rust library documentation.
While doing this I found a safety bug in `OutPtr::from_opt_ptr`:
it should have been using `MaybeUninit`.
These macros should allow us to build a "proof sketch" for the
safety of our FFI code. We need to show, for each input parameter:
- That the documented requirements for its conversion method
are also documented requirements for that kind of input, in our
header file.
- That the documented requirements for how it can be used
after conversion are in fact followed in the code.
Rename Utf8CStr=>Utf8CString2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-25T17:58:01Zurn:sha1:31d3c76529abd72dbb224b0bb41a9e8ff425fcb9rpclib ffi: Grand identifier renaming2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-25T15:06:54Zurn:sha1:851cd0a7032b7bcc2689c36afed7a5ef1b820326
In brief: Everything now starts with ARTI_RPC, arti_rpc, or ArtiRpc.
rpclib: Revise/condense "safety" docs for C functions2024-07-31T17:54:16ZNick Mathewsonnickm@torproject.org2024-07-25T14:40:04Zurn:sha1:a9334b3cb2a60387ede0c3a83bb348ecd25f5cc9
These documents are no longer called "safety". They are now mostly
collected as a big list of "correctness requirements" at the start
of the cbindgen header. Because of these requirements, most
functions no longer need their own "safety" sections.
I am explicitly using `#[allow(clippy::missing_safety_doc)]` on each
function, rather than adding a blanket exception:
- There are other unsafe functions in this code, to which we
wouldn't want an exception to apply.
- Documenting the safety^W correctness requirements of a function
is important enough to make sure that we aren't skipping out on
it unintentionally.