Skip to content

Fix #761: pad Smile async parser name quads like blocking parser - #765

Open
kalayciburak wants to merge 1 commit into
FasterXML:2.21from
kalayciburak:761-smile-async-nul-padding
Open

Fix #761: pad Smile async parser name quads like blocking parser#765
kalayciburak wants to merge 1 commit into
FasterXML:2.21from
kalayciburak:761-smile-async-nul-padding

Conversation

@kalayciburak

Copy link
Copy Markdown

Fixes #761

The blocking SmileParser pads unused high bytes of a partial name quad (_padQuadForNulls) so a short name cannot collide with a longer NUL-prefixed one in ByteQuadsCanonicalizer (#312). The non-blocking parser still zero-padded those leftover bytes.

Apply the same 1s-padding on every partial quad in:

  • NonBlockingParserBase._findDecodedFromSymbols (len < 5 and the q2 tail of len < 9)
  • NonBlockingParserBase._findDecodedLonger leftover 1-3 bytes
  • NonBlockingByteArrayParser._finishLongFieldName leftover 1-3 bytes

Targeting 2.21 as requested on the issue (bug is present there; merge-forward can carry it).

Tests

  • ../mvnw -Dtest=AsyncSymbolTable312Test test (RED before the change: async reported \"\\0\\0\\0a\" twice instead of \"\\0\\0\\0a\" then \"a\"; GREEN after)
  • ../mvnw -Dtest=AsyncSymbolTable312Test,SymbolTable312Test,AsyncParserNamesTest test: 12/0
  • ../mvnw test in smile/: 267 tests, 4 skipped, 0 failures

…rser

Unused high bytes of a partial name quad were left as zeros, so a
short name collided with a longer NUL-prefixed one in the symbol
table. Match SmileParser's 1s-padding on every partial quad.
@cowtowncoder cowtowncoder added the cla-received Marker to denote that there is a CLA for pr label Aug 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-received Marker to denote that there is a CLA for pr

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants