This does the changes for all crates other than fuel-merkle, which will be done in a separate PR.
Denies the following lints:
clippy::arithmetic_side_effects
clippy::cast_sign_loss
clippy::cast_possible_truncation
clippy::cast_possible_wrap
The following bugs were fixed:
UtxoId::from_str now rejects inputs with multiple 0x prefixes
array and numeric wrapper types like AssetId and BlockHeight now reject extra bytes in their from_str implementation (these were ignored before)
Some improvements were also done:
from_str error messages now indicate which type caused the error
Some changes introduce Rust-level panics where normally an overflow would have only panicked on debug mode.
Memory offsets of several types were previously calculated using unchecked operations. This PR changes those to use saturating_* operations instead. This means that given incorrect consensus parameters, some operations that previously overflowed silently know instead give memory offsets outside VM ram, causing a VM-level panic on access. This is strictly an improvement over previous behavior, but still leaves a lot to be desired. I'm not sure if it's actually possible to do much better, though. Maybe with custom types? The current approach feels like the most sensible tradeoff.
Checklist
[x] Breaking changes are clearly marked as such in the PR description and changelog
[x] New behavior is reflected in tests
Before requesting review
[x] I have reviewed the code myself
[x] I have created follow-up issues caused by this PR and linked them here
Work towards #170
This does the changes for all crates other than
fuel-merkle, which will be done in a separate PR.Denies the following lints:
clippy::arithmetic_side_effectsclippy::cast_sign_lossclippy::cast_possible_truncationclippy::cast_possible_wrapThe following bugs were fixed:
UtxoId::from_strnow rejects inputs with multiple0xprefixesAssetIdandBlockHeightnow reject extra bytes in theirfrom_strimplementation (these were ignored before)Some improvements were also done:
from_strerror messages now indicate which type caused the errorSome changes introduce Rust-level panics where normally an overflow would have only panicked on debug mode.
Memory offsets of several types were previously calculated using unchecked operations. This PR changes those to use
saturating_*operations instead. This means that given incorrect consensus parameters, some operations that previously overflowed silently know instead give memory offsets outside VM ram, causing a VM-level panic on access. This is strictly an improvement over previous behavior, but still leaves a lot to be desired. I'm not sure if it's actually possible to do much better, though. Maybe with custom types? The current approach feels like the most sensible tradeoff.Checklist
Before requesting review