GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||
GeezerVison is showing github.com — src: fix decoding base64 with whitespace by seishun · Pull Request #13660 · nodejs/node Conversation
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I've replaced "buffer" with "src" in the commit message since this code isn't used just for the buffer module. Any objections? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Sorry for being so late – can you also include the patch from #13636? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I'm having reservations about including it here, it seems barely related, and would probably confuse someone looking at the commit. Besides, that patch isn't a proper fix for the test since null char is a valid byte. The right thing would be to compare the decoded length with the expected length. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
You can totally include it as a separate commit, if that helps. (If you don’t want to include it, fine by me – but we should fix the test in any case.)
Right, good point. I’d be okay with accepting that because our expected texts don’t contain null chars, but if you have reservations I can do a PR myself. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Right, they don't, but what if our base64_decode implementation starts erroneously padding its output with nulls? The test should fail then.
That would be great. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
`max_i` should also include the characters that were just read by `base64_decode_group_slow()`. PR-URL: #13660 Fixes: #13636 Fixes: #13657 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Alexey Orlenko <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
`max_i` should also include the characters that were just read by `base64_decode_group_slow()`. PR-URL: #13660 Fixes: #13636 Fixes: #13657 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Alexey Orlenko <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
|
Should this be backported to v6.x? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
If it applies cleanly, then yes. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
If not, we should probably still backport the test piece here. (edit: to be clear, that passes on its own on 6.11.1) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@MylesBorins this PR fixes a bug introduced in #12146, so it depends on whether that patch was backported or not. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
opted to not land, please feel free to manually backport the test |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
base64 decoding drops characters when there is whitespace in the middle Making base64 cctest deterministic makes it fail
There was an error while loading. Please reload this page.