The endian-num crate offers some feature to effectively enforce endianness of certain types. This is something that may easily be integrated into can-types to provide endianness guarantees since some ECUs can be strictly Big-Endian or Little-Endian. Developers using this can, in theory, have some reassurance that their usage of can-types is behaving as expected.
For example, a type using endian-num has a Little-Endian byte order even on Big-Endian machines, or vice versa.
Implementing this might require adding additional conditional feature flags or macros. Some initial testing also indicates that a new branch build could be the simplest implementation.
Caveats:
Using endian-num might limit crate compatibility to linux since the types we'd use are behind a "linux-types" feature gate, although, I'm not sure if this would even be a valid concern.
The endian-num crate offers some feature to effectively enforce endianness of certain types. This is something that may easily be integrated into
can-typesto provide endianness guarantees since some ECUs can be strictly Big-Endian or Little-Endian. Developers using this can, in theory, have some reassurance that their usage of can-types is behaving as expected.For example, a type using
endian-numhas a Little-Endian byte order even on Big-Endian machines, or vice versa.Implementing this might require adding additional conditional feature flags or macros. Some initial testing also indicates that a new branch build could be the simplest implementation.
Caveats:
endian-nummight limit crate compatibility to linux since the types we'd use are behind a "linux-types" feature gate, although, I'm not sure if this would even be a valid concern.