Editorial: assert the FromBase64 multiple-of-3 byte invariant#3875
Open
ljharb wants to merge 1 commit into
Open
Editorial: assert the FromBase64 multiple-of-3 byte invariant#3875ljharb wants to merge 1 commit into
ljharb wants to merge 1 commit into
Conversation
ljharb
added a commit
to ljharb/ecma262
that referenced
this pull request
May 19, 2026
) `FromBase64` only appends bytes via `DecodeFullLengthBase64Chunk` (always 3 bytes at a time) inside step 10.l, and step 10.i preempts further reading when continuing to the next full chunk would exceed `maxLength`. Together these guarantee that, at the top of each iteration of the Repeat loop, the number of elements in `bytes` is a multiple of 3; partial outputs (1 or 2 bytes) only ever occur at end-of-stream via `DecodeFinalBase64Chunk` (step 10.b.i and step 10.e). This invariant is currently implicit; making it an explicit Assert clarifies the algorithm's structure for both readers and implementers (e.g., it justifies why step 10.i's two conditions are exhaustive)
ljharb
force-pushed
the
ljharb/frombase64-multiple-of-three-assertion
branch
from
7f9fbe3 to
8a9213a
Compare
|
The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/3875 and as multiple pages at https://tc39.es/ecma262/pr/3875/multipage . |
bakkot
approved these changes
May 19, 2026
michaelficarra
approved these changes
May 20, 2026
) `FromBase64` only appends bytes via `DecodeFullLengthBase64Chunk` (always 3 bytes at a time) inside step 10.l, and step 10.i preempts further reading when continuing to the next full chunk would exceed `maxLength`. Together these guarantee that, at the top of each iteration of the Repeat loop, the number of elements in `bytes` is a multiple of 3; partial outputs (1 or 2 bytes) only ever occur at end-of-stream via `DecodeFinalBase64Chunk` (step 10.b.i and step 10.e). This invariant is currently implicit; making it an explicit Assert clarifies the algorithm's structure for both readers and implementers (e.g., it justifies why step 10.i's two conditions are exhaustive)
ljharb
force-pushed
the
ljharb/frombase64-multiple-of-three-assertion
branch
from
8a9213a to
f3d8a11
Compare
linusg
approved these changes
May 21, 2026
linusg
added
the
ready to merge
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
4 participants
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.
FromBase64only appends bytes viaDecodeFullLengthBase64Chunk(always 3 bytes at a time) inside step 10.l, and step 10.i preempts further reading when continuing to the next full chunk would exceedmaxLength. Together these guarantee that, at the top of each iteration of the Repeat loop, the number of elements inbytesis a multiple of 3; partial outputs (1 or 2 bytes) only ever occur at end-of-stream viaDecodeFinalBase64Chunk(step 10.b.i and step 10.e).This invariant is currently implicit; making it an explicit Assert clarifies the algorithm's structure for both readers and implementers (e.g., it justifies why step 10.i's two conditions are exhaustive)