* CBOR uses Vec for map internally
* remove BTreeMap from get_info
* rename cbor_map_btree and clean up cbor_array_vec
* destructure now takes Vec, not BTreeMap
* adds dedup in CBOR writer
* fail to write CBOR maps with duplicates
* CBOR interface refinements
* macro documentation for CBOR map and array
Those need the driver to deal with the fact that the store is stateful. Those
tests can't be moved to the test suite because they use private functions.
With dirty storage we hit the assert. Returning an error permits to continue to
catch if the invariant is broken for normal operation while being able to
continue fuzzing with dirty storage.
We don't need to build a production key without persistent storage. Tests and
fuzzing continue to use the std feature to use the RAM implementation (that does
sanity checks).
We prefer to return those errors to the fuzzer which can then decide whether
they are expected or not (e.g. when starting from a dirty storage, the store is
expected to have errors).
This PR does the following things:
- Give incompatible representations for integers with different semantics:
- `usize` is used for natural numbers for the public API.
- `Nat` is used internally for natural numbers (essentially a stable `usize`).
- `Word` is used for sequences of bits representing words in flash.
- `Position` is used for word positions in the virtual storage.
- Only use fixed size integers to preserve overflow behavior between targets.
- Use little-endian representation instead of native representation for `Word`.
Alternatives:
- Run tests and fuzzing on 32-bits architecture (or some compatibility mode).
This approach would have better readability than the current solution (less
conversions at public API). However it would require additional setup and
might not be viable long-term by restricting machines on which fuzzing is
possible.
- Accept the behavior difference for tests and fuzzing. This approach would also
have better readability. However checking for arithmetic overflow (and other
`usize` related concerns like memory size) is more important.
