I just published a crate for representing semantic versions as integers (i32, i64, etc.) (see https://docs.rs/embedded-semver/0.1.0/embedded_semver), but wanted to make sure that there's nothing fancy going on in the docs or internals relating to the endianness (disclaimer: I haven't done much work with bit-mangling).
Packet structure in 32-bit environments:
0 2 12 22 32 ├────┴────┼┴┴┴┴┴┴┴┴┴┼┴┴┴┴┴┴┴┴┴┼┴┴┴┴┴┴┴┴┴┤ │ API ver │ Major │ Minor │ Patch │ │ u2 │ u10 │ u10 │ u10 │ └─────────┴─────────┴─────────┴─────────┘
api version = magic number that allows extending the crate in future for different storage representations.
So basically one can do:
let version = Semver::new(1, 0, 20); let int_semver = version.to_i32().unwrap(); assert_eq!(int_semver, 83886081); assert_eq!(&int_semver.to_le_bytes(), &[0b0000_0001, 0b0000_0000, 0b0000_0000, 0b0000_0101]);
What I'm concerned about, is the ordering of bytes "right" by convention here? E.g. in the slice before
&[0b00 the first bits
00 would be the API version (
00 = 0,
01 = 1,
10 = 2, etc.).
What about the whole byte array, does the actual slice above conform to the documentation? Are bytes read from left-to-right (0-32) or right-to-left?
So if I understand correctly, these fields (api ver, major, minor, patch) are big-endian (most significant bytes first), but what about the whole 4-byte field ordering?
There's also the
to_le_bytes conversion that results to the byte slice above.