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

fmt: Fscanln misbehaving and taking an extra rune #3833

gopherbot opened this issue Jul 16, 2012 · 4 comments

fmt: Fscanln misbehaving and taking an extra rune #3833

gopherbot opened this issue Jul 16, 2012 · 4 comments


Copy link

@gopherbot gopherbot commented Jul 16, 2012

by iJonCarroll:

What steps will reproduce the problem?
If possible, include a link to a program on
1.see, and enter "abc def ghi" or similar in a single line, press return
3.observe the output, note that the first rune of second and third words are missing

What is the expected output?

What do you see instead?

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g (I assume - standard windows distribution on x86 32bit)

Which operating system are you using?
Windows XP SP3

Which version are you using?  (run 'go version')

Please provide any additional information below.

Note - Have read "Note: Fscan etc. can read one
character.. [..] .. If the reader also implements UnreadRune, that method will be used
to save the character and successive calls will not lose data." 

My interpretation was that the use of "UnreadRune" was automatic, (built into
the pkg), and would apply to "Fscanln" as well as "Fscan".

Truncating behaviour also observed with Scanln.

As far as I can tell "fmt.Fscan" works without an explicit
"UnreadRune" with no truncation

Desired behaviour is got if "source.UnreadRune()" is un-commented in the
supplied program - but I was not expecting to have to use it.
Copy link

@gopherbot gopherbot commented Jul 16, 2012

Comment 1 by iJonCarroll:

..more.. (just noticed) also try entering "1 2 3 4 5 6 7 8" (note an even number of
terms) result is "1 3 5 7 7" (doesn't happen with an odd number) - this is definitely
off spec.
Copy link

@gopherbot gopherbot commented Jul 16, 2012

Comment 2 by iJonCarroll:

(..yet more..) I should probably file a bug report for the behaviour of Scanln under the
conditions above. ie entry of an even number of space separated single rune values.
Skipping every other entry is understandable under these conditions (eaten rune), but
the return of the same value twice isn't explicable/predictable.
entering "1 2 3 4 5" returns '1 3 5' - can understand - predictable from package
but entering 1 2 3 4 5 6" returns '1 3 5 5' - not predicted from docs.
Copy link

@robpike robpike commented Jul 16, 2012

Comment 3:

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

Owner changed to @robpike.

Status changed to Accepted.

Copy link

@robpike robpike commented Aug 2, 2012

Comment 5:

If you get an error from Fscanln (or any other such function), you can't predict the
state of the input. It could be anything. Fscanln reads a line and you're not giving it
a line that matches the value[s] being read.
You want to use fmt.Fscan for this kind of input or, if you know have three inputs, give
three arguments.

Status changed to WorkingAsIntended.

@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.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.