You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently, a user must either mark Example as repr(C, packed), or they must model Example instead as a composite struct containing Refs to the Header and [Body].
Can we make our analysis more sophisticated in this case?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: