Open jswrenn opened 5 months ago
In theory, the impl of KnownLayout
contains enough information to determine whether it's guaranteed that there will never be any padding between any of the fields or after body
. However, relying on that would mean adding the assumption that KnownLayout
is also derived. For non-repr(C)
types, this is fine (since KnownLayout
isn't supported for such types, we would know not to even try). For repr(C)
types, we would have to choose between either assuming KnownLayout
or sticking with the current analysis, which doesn't permit types like this.
Note that even the problem of detecting whether or not a type is unsized is hard - there's no syntactic way to determine whether a concrete type is unsized.
Many dynamically sized types can be
derive(FromBytes)
but notderive(IntoBytes)
because of shortcomings in our padding analysis. For example:Presently, a user must either mark
Example
asrepr(C, packed)
, or they must modelExample
instead as a composite struct containingRef
s to theHeader
and[Body]
.Can we make our analysis more sophisticated in this case?