I guess not, but since it uses a plain io.Reader which doesn't support peek or pushback, I can't think of any other behavior which is possible.
On Thursday, 30 January 2025 at 19:27:51 UTC tapi...@gmail.com wrote: > On Tuesday, January 28, 2025 at 7:07:15 PM UTC+8 Brian Candler wrote: > > > The documentation tells that Fscanln() is similar to Fscan(), my test > shows that it isn't true for some cases. > > "similar" does not mean "the same as". > > Fscanln chomps the fields given, then chomps the next character. If the > next character is newline, it's happy. If the next character is not a > newline, then it's unhappy and returns an error. At this point, you know > the input was bad. > > No guarantees are made about the state of the input after an error, and as > you've found, the next character (which *should* have been a newline) has > been chomped. > > > It looks the eating/chomping behavior is not well documented. > > > > On Tuesday, 28 January 2025 at 10:07:28 UTC Ivan Burak wrote: > > Hi Howard > > Thank you for the answer. > > My data is easier, it contains only 2 lines: > Go version go1.22.11 windows/amd64 > Build simple, secure, scalable systems with Go > > I did some tests and to speedup coding decided to use Fscanln(). > I don't use this function in real programming, it's too slow. > There are many ways to parse texts in Golang that fast and stable. > > My test algorithm didn't work, and when I realized what the reason was, I > was just surprised. > The documentation tells that Fscanln() is similar to Fscan(), my test > shows that it isn't true for some cases. > In my opinion the documentation or the function should be corrected. > That's it. :) > > >> fmt.Fscanln(in2,&one,&two,&three,&four) > That works but you know in our profession, usually we don't know the exact > amount of data being processed > (number of tokens, records, data volumes etc.), so we have to code based > on estimates n, n^2, n^3 ... and we don't know the real n. > > thanks > ivan > > On Monday, January 27, 2025 at 11:29:32 PM UTC+3 Howard C. Shaw III wrote: > > In your example, you are repeatedly reading one 'item' from the line. This > is the source of the confusion, as this is not how Fscanln works - when you > do this, *each* item is the documented 'final item' after which there must > be a newline. > > That is, your data would look more like this: > space separated column headers > first second third last > some data with the > same pattern of columns > > and your read would be pulling all of those items from one line: > fmt.Fscanln(in2,&one,&two,&three,&four) > > It is expected/designed to read one line of data at a time, and for you to > know in advance the number of items in the line, and to expect to receive > an error if they don't match. It is also expected that each column will > have a consistent datatype, and for that to match the types of your > parameters, and to error if the data can't be parsed. > > For parsing arbitrary string data, you might be better off just using > bufio.Scanner with bufio.ScanWords. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/f3399f51-3d28-4b50-861d-230718ccfb3bn%40googlegroups.com.
