fix: pad Address6#toByteArray to a full 16 bytes#209
Open
spokodev wants to merge 1 commit into
Open
Conversation
`bigInt().toString(16)` drops high-order zero nibbles, so `toByteArray()` and `toUnsignedByteArray()` returned a short array for any address with leading zero bytes. `::1` yielded `[1]` and `::` yielded `[0]` instead of the documented 16-byte representation, which breaks `Buffer.from(...)` for fixed-width network and storage use. Pad the hex string to `BITS / 4` nibbles (16 bytes), matching the existing `binaryZeroPad()` approach and the `Address4#toArray` sibling, which already returns a fixed-width array.
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
1 participant
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.
An IPv6 address is a 128-bit (16-octet) identifier per RFC 4291 §2, but
Address6#toByteArray()andtoUnsignedByteArray()return a variable-length array that drops high-order zero bytes:The documented use is
Buffer.from(address.toByteArray()), so for::1you get a 1-byte buffer instead of the 16-byte address. This breaks fixed-width consumers: socket/packet builders, DBBINARY(16)/inetcolumns (cf. #23), dedup/ACL byte comparisons, and any pre-sized buffer. It affects roughly half of all addresses (anything with a zero top byte: loopback, unspecified, link-localfe80::, ULA, documentation2001:db8::, IPv4-mapped, NAT64).Cause
bigInt().toString(16)drops leading zero nibbles. The existingleadingPadonly restores odd-nibble parity (the fix for the length-17 case in #40), never whole zero bytes.Fix
Pad the hex to
BITS / 4(32) nibbles, mirroring the existingbinaryZeroPad()(toString(2).padStart(BITS, "0")) and theAddress4#toArraysibling, which already returns a fixed-width array.fromByteArray/fromUnsignedByteArrayalready read big-endian, so round-tripping is unchanged.Tests
Strengthened the existing round-trip assertions from
length.should.be.at.most(16)toequal(16), and added focused cases for leading-zero addresses (::,::1,::ffff:192.168.0.1). These fail on the current code and pass with the fix; full suite green.