dwrensha
commented
7 years ago Probably the most straightforward way to reduce the amount of unsafe code would be use slices instead of raw pointers. For example, in ListReader, the ptr field could be a &[Word] instead of a *const u8. There are a lot of details to hammer out about how exactly to make this work, and such a change would probably entail some performance overhead, but perhaps the added safety would be worth it.
A more ambitious approach would be to use formal methods. It would be really cool if we had a theorem prover that allowed us verify that the unsafe code does the right thing. The invariants that need to be upheld in layout.rs seem simple enough; mainly we need to verify that the results of various pieces of integer arithmetic stay within certain bounds. With a few annotations sprinkled in, an automated prover should have no trouble checking whether those invariants hold. Unfortunately, as far as I know, no such prover exists for Rust yet. (In fact, part of my motivation for working on seer is to understand what such a prover might look like.)
DemiMarie
indo-dev-0
Currently, the code (especially layout.rs) is horribly unsafe. In fact, it appears less safe than even the C++ version, which uses template metaprogramming to catch overflow at compile time.
While the interface claims to be safe, the amount of unsafe code in the implementation is worrying when security is a concern. Most of the unsafety seems to appear as a result of accessing fields essentially by raw pointer arithmetic. One solution might be to generate a
#[repr(packed)]struct type that represents the actual data off of the wire. Accessing this struct is then safe, at least once one has a reference (by necessity shared) to it. Rust provides#[inline]to ensure that the accessors inline away and have zero overhead.