fmt: Fscanln misbehaving and taking an extra rune

[gopherbot]

by iJonCarroll:

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1.see http://play.golang.org./p/SEMHqPEOJD
2.run, 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?
"abc"
"def"
"ghi"


What do you see instead?
"abc"
"ef"
"hi"

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')
go1.0.2

Please provide any additional information below.

Note - Have read http://golang.org/pkg/fmt/#Scanning "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.

[gopherbot]

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.

[gopherbot]

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.
eg:
entering "1 2 3 4 5" returns '1 3 5' - can understand - predictable from package
documentation
but entering 1 2 3 4 5 6" returns '1 3 5 5' - not predicted from docs.

[robpike]

Comment 3:

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

Owner changed to @robpike.

Status changed to Accepted.

[robpike]

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.