Repository navigation
Fix base58 encoding losing leading zero bytes - #48
sumanjeet0012 wants to merge 2 commits into
Conversation
c3b4976 to
7c1aaef
Compare
acul71
left a comment
There was a problem hiding this comment.
Review (maintainer) — Request changes
Thanks for tackling #35. The diagnosis is right, and non-all-zero leading-zero payloads round-trip correctly. I’m still requesting changes and prefer overlapping PR #55 for landing this fix.
Prefer #55
- #55 fixes the same
BaseStringConverterleading-zero bug, handles all-zeros and empty inputs, addstests/test_roundtrip.pyacross all encodings, and has green CI. - #48 currently has no CI checks reported on
fix-issue-35-leading-zeros. - Please treat #55 as the preferred merge vehicle. Leaving this PR open (not closing) for reference / coordination.
Blockers
- Missing newsfragment — add
newsfragments/35.bugfix.rst(user-facing ReST + trailing newline). Mandatory for approval on this track. - All-zeros off-by-one —
super().encode(0)already emits the zero digit, then leading zeros are prepended again. Locally:encode("base58btc", b"\x00")→z11(expectedz1); decode yields an extra\x00. Same pattern for other integer bases. - Empty input —
encode("base58btc", b"")→z1/ decodes tob"\x00". Needs an empty-input special case (as in #55).
Other notes
- Branch is 6 behind / 1 ahead of
origin/master; dry-run merge was clean (no conflicts) but should be synced if this PR continues. - New fixtures only cover
\x00\x00+ non-zero payload; they don’t catch the all-zeros/empty bugs. - Local
make lint,typecheck,test(287 passed),docs-ciall passed on the PR worktree — but CI absence on GitHub remains a concern. - Minor: parameter name
bytesshadows the builtin;hasattr(..., "decode")is weaker than #55’sisinstance+ rename.
Bottom line: Request changes — missing newsfragment, incomplete edge cases, no CI, superseded by stronger #55. Do not merge #48 as-is; prefer #55.
|
Hi @sumanjeet0012 — friendly follow-up. I requested changes on this PR on 2026-09-07 (mainly the missing towncrier newsfragment, plus the other notes in that review). I don’t see any new commits addressing those items yet. Are you still willing / able to carry this PR forward? If yes, please push the requested updates when you can and I’ll re-review promptly. If your bandwidth has changed, no worries — just say so and we can close it or leave it for someone else to pick up. |
🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
Fixes #35
This PR fixes the issue where
BaseStringConvertersilently drops leading\x00bytes during encoding and decoding for integer-based encodings (likebase58btc). It now properly counts and preserves them by utilizing the encoding alphabet's zero character.Changes made:
BaseStringConverter.encode()anddecode()to manually handle leading zero bytes.Base16StringConverter.decode()to usebytes.fromhex()directly to bypass the zero-counting logic, as base16 operates byte-by-byte.base58btc,base58flickr,base32z,base36,base10,base8, andbase2with leading zero byte strings to ensure correct round-tripping.All 287 tests pass successfully.