dunglas / httpsfv

92%

master: 93%

LAST BUILD ON BRANCH fix-maximal-length-number

branch: fix-maximal-length-number

CHANGE BRANCH

x

Reset

• fix-maximal-length-number
• chore/go1.19
• ci/modernize
• decimal-fix
• dependabot/submodules/structured-field-tests-00462dd
• feat/rfc
• feat/rfc9651
• fix-ci-submodule-and-multiline-join
• fix/linter
• main
• master
• refs/tags/v0.1.0
• refs/tags/v0.1.1
• refs/tags/v1.0.0
• refs/tags/v1.0.1
• refs/tags/v1.0.2
• refs/tags/v1.1.0
• refs/tags/v1.1.1
• reject-nan-decimal
• tests/fuzz

Build # 34078401663

Build Type

Pull #15

github

Committed by youdie006

Commit Message

fix: Do not reject a maximal-length number followed by a delimiter

parseNumber evaluates the length bound at the top of the loop, before
looking at the next character, so a 15-digit integer or 16-character
decimal fails as soon as anything follows it. RFC 9651 section 4.2.4
appends the character first and fails only when input_number already
holds more than 15 or 16 characters, so those inputs are valid.

marshalInteger allows the full +/-999999999999999 range, so the library
emits headers it cannot read back: Marshal of a list containing
123456789012345 and 1 gives '123456789012345, 1', and UnmarshalList of
that string returns 'integer or decimal out of range: character 15'.

Move the check after the digit is consumed and compare with > instead
of >=, matching the form the '.' branch already uses.

Pull Request Pull Request #15: fix: Do not reject a maximal-length number followed by a delimiter

Coverage Stats

4 of 4 new or added lines in 1 file covered. (100.0%)

651 of 711 relevant lines covered (91.56%)

46.07 hits per line