Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
fmt: Fscanln misbehaving and taking an extra rune #3833
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.
(..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.
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.