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
These are kinds of validity that users may need to have checked before transmutation from &[u8] to &T:
The language-level validity of the bits for the type of each field in T, e.g. a bool must be either 0 or 1. This is implemented by the derive.
The library-level validity of the bits in T, e.g. an invariant that the first field is less than the second. This can be referenced by the derive but inherently must be user-controlled.
The library-level validity of the individual fields in T, based on the above library-level check applied to each field. This is also implemented by the derive.
The library-level validity of the length of the struct given the header contents, e.g. the length field is equal to the size of the tail slice. This only applies to dynamically sized structs ending in a slice.
The plan discussed in #5 and #372 is to support the concept of a custom validator, a function or closure provided to derive(TryFromBytes) that will always be called before allowing a TryFromBytes transmute to succeed.
Open Questions
Should users be able to provide their own error type, to communicate the way in which the validation failed? How would this be exposed to the higher-level TryFromBytes APIs?
What happens if the user provides both a #[length] and custom validator function and they disagree?
Given struct Outer { x: u8, y: Inner }/struct Inner { a: [u8; 4], b: [u8] }, is the validator for Outer allowed to communicate a maximum length for the tail slice located inside of Inner? What if Inner has a custom validator that returns "valid if the tail slice is truncated to N", but Outer has a different return from its custom validator?
What are the required signature(s) for the custom validators? In theory the derive can support many return types simultaneously, including bool, Result<(), CustomError>, or Result<Option<usize>, CustomError> (to communicate a required length).
When zerocopy's expectations surrounding validator behavior are violated, should it panic (terrible for embedded), only panic in debug mode (middle ground a la + overflow checking), or always reject the input (could miss bugs in validators).
The text was updated successfully, but these errors were encountered:
These are kinds of validity that users may need to have checked before transmutation from
&[u8]
to&T
:T
, e.g. abool
must be either0
or1
. This is implemented by thederive
.T
, e.g. an invariant that the first field is less than the second. This can be referenced by thederive
but inherently must be user-controlled.T
, based on the above library-level check applied to each field. This is also implemented by thederive
.length
field is equal to the size of the tail slice. This only applies to dynamically sized structs ending in a slice.The plan discussed in #5 and #372 is to support the concept of a custom validator, a function or closure provided to
derive(TryFromBytes)
that will always be called before allowing aTryFromBytes
transmute to succeed.Open Questions
TryFromBytes
APIs?KnownLayout
type with a user-provided length computed dynamically #1289 (comment))?#[length]
and custom validator function and they disagree?struct Outer { x: u8, y: Inner }
/struct Inner { a: [u8; 4], b: [u8] }
, is the validator forOuter
allowed to communicate a maximum length for the tail slice located inside ofInner
? What ifInner
has a custom validator that returns "valid if the tail slice is truncated to N", butOuter
has a different return from its custom validator?bool
,Result<(), CustomError>
, orResult<Option<usize>, CustomError>
(to communicate a required length).+
overflow checking), or always reject the input (could miss bugs in validators).The text was updated successfully, but these errors were encountered: