Skip to content
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: NUL byte in input leads to wrong output #4394

Closed
gopherbot opened this issue Nov 15, 2012 · 6 comments
Closed

encoding/base64: NUL byte in input leads to wrong output #4394

gopherbot opened this issue Nov 15, 2012 · 6 comments
Milestone

Comments

@gopherbot
Copy link
Contributor

by mstplbrg:

What steps will reproduce the problem?
1. Run this go program: http://play.golang.org/p/J6885vjGRj — it base64-encodes
"foo\x00bar"
2. Run base64 -d on the output ("echo Zm9vAGJh | base64 -d")
3. You get "fooba" instead of "foo\0bar"

What is the expected output?
Zm9vAGJhcgo=

What do you see instead?
Zm9vAGJh

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g

Which operating system are you using?
Linux (Debian testing)

Which version are you using?  (run 'go version')
go version devel +4d46cae98846 Thu Nov 15 11:46:00 2012 -0800
@robpike
Copy link
Contributor

robpike commented Nov 16, 2012

Comment 1:

I believe the code is working and that your test is confused by the NUL. If I s/d/D/ (on
mac) in your test, I see your output, but this code works as it should:
http://play.golang.org/p/OzNsC8fhDB
I believe the base64 tool or Unix output routines may be at fault here, not the Go
library.
Now, the string you expect to see, ending in =, produces a different result when I
decode it: it includes a newline.
http://play.golang.org/p/JSFuw7sNEo
I believe things are working as intended but it's confusing enough I'll leave it open
and let you respond. Case is not yet proven to my satisfaction.

Status changed to WaitingForReply.

@gopherbot
Copy link
Contributor Author

Comment 2 by mstplbrg:

Thank you for your reply.
You are indeed correct that my expected output from my original report contains a
newline. Here is how to fix it:
$ echo -n 'foo\0bar' | base64
Zm9vAGJhcg==
This value (Zm9vAGJhcg==) is still different from the Go result (Zm9vAGJh).
The code you posted as "works as it should" (http://play.golang.org/p/OzNsC8fhDB)
produces the following output when run on play.golang.org:
"Zm9vAGJh"
"foo\x00ba"
The problem here is that the last "r" is missing. That is, the output should be
"foo\x00bar", not "foo\x00ba".
I hope this clarifies things :-). Thanks for looking into this!

@robpike
Copy link
Contributor

robpike commented Nov 19, 2012

Comment 3:

Labels changed: added priority-soon, removed priority-triage.

Status changed to Accepted.

@gopherbot
Copy link
Contributor Author

Comment 4 by mstplbrg:

I figured out what the problem was:
I neglected to call encoder.Close(), even though the documentation states it is
necessary. So turns out the \0 is not the problem and in fact works as it should :-).
This issue can be closed.

@minux
Copy link
Member

minux commented Nov 29, 2012

Comment 5:

I copied your test case and turned it into an example for encoding/base64
to emphasize the importance of encoder.Close().
http://golang.org/cl/6847125

@minux
Copy link
Member

minux commented Dec 11, 2012

Comment 6:

This issue was closed by revision 15353d2.

Status changed to Fixed.

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants