-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
encoding/base64: decoder output depends on chunking of underlying reader #31626
Comments
cc @zegl |
The bug still exists with 1.14.2. I'm not sure why this issue got the Proposal label; it's just a bug in the base64 package.
Here is another demonstration of the bug. Here, the same input is given to a decoder, each time split differently. The output should always be the same, but it is not. It's not hard to imagine a case where a decoder is reading from a network socket, say, and accepts or rejects an input depending on where packet boundaries happen to fall.
|
Yes, this looks like a bug. Not sure why it got a proposal label. |
I will work on this. |
Change https://golang.org/cl/246377 mentions this issue: |
The output of a decoder produced from Encoding.NewDecoder differs depending on how you chunk the input to it. I noticed these differences:
=
characters not at the end of the stream). For example, decoding["QQ==Qg=="]
(correctly) results in an error, but["QQ==", "Qg=="]
(incorrectly) decodes to"AB"
.["AAAA####"]
says the error occurs at offset 4, but decoding["AAAA" "####"]
says the error occurs at offset 0.I think that the output of a decoder should always be the same as if the entire Reader were serialized to a string and then passed to DecodeString.
Item 1 is more important IMO. Item 2 was unexpected but I can live with inconsistent byte offsets in error messages. However seeing as CorruptInputError is already an int64, it would be nice to have if it doesn't complicate the internals too much.
This bug is somewhat similar to #25296 for encoding/base32.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes, using go1.12 on play.golang.org
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
https://play.golang.org/p/6rcDYtro36S
What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: