Read the REAL mantissa as an unsigned integer and check exponent scaling - #146
Open
dzatona wants to merge 1 commit into
Open
Read the REAL mantissa as an unsigned integer and check exponent scaling#146dzatona wants to merge 1 commit into
dzatona wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses the first and third defects in #143. The exponent-format defect is
left alone — that one changes which inputs are accepted, so it is a separate
decision.
Two changes in
decode_real:The mantissa is accumulated into
u64instead ofi64, with the sign appliedat the conversion to
f64. X.690 8.5.7.5 defines N as an unsigned binarynumber, so bit 63 of an eight-octet mantissa is a value bit, not a sign bit.
Today
09 0a 80 00 80 00 00 00 00 00 00 01decodes as-9.223372036854776e18in every profile; with this it decodes positive. The samechange removes the negation overflow, since there is no longer a negation of
i64::MINto overflow.u64rather thani128because the existingrem.len() > 8guard already capsN at eight octets, so
u64represents every mantissa the crate accepts, exactly.checked_mulon the base-8 and base-16 exponent scaling, returningInvalidValue { msg: "Exponent out of range (REAL)" }. This is reachable onBER-conforming input today — a 37-byte value with
X = 32gets its exponentmisread as
20 01 00 00, ande * 4leavesi32before the mantissa-lengthguard is consulted — and it stays reachable if the exponent-format defect is
fixed, because
X = 4remains legal and a four-octet exponent spansi32. Sothis part stands on its own regardless of what happens to the format handling.
Three tests in
tests/ber.rs, in the style of the existingfrom_ber_real_*ones: the unsigned mantissa, the most-negative mantissa, and four inputs that
must be rejected for exponent range — the two short malformed ones plus both
minimal BER-conforming forms, 48 bytes for base 8 and 37 for base 16. All three
fail against an unpatched
real.rs.cargo fmt --check,cargo clippy --all-features --all-targets -- -D warningsand
cargo test --all-featuresare clean: 466 tests, no existing test changed.Both build profiles now agree on every input I have, which they did not before.
The CI failures on this branch are the
compile_failtrybuild mismatch alreadypresent on
master— a rustc diagnostic reworded since the.stderrwasrecorded. Not related to this change.