Similarly, Scanf is inconsistent when providing a prefix in the format

// results in io.EOF error
_, err = fmt.Sscanf("", "%d\n", &foo)

// results in io.ErrUnexpectedEOF
_, err := fmt.Sscanf("", "prefix %d\n", &foo)

I also expect io.EOF in the latter

https://play.golang.org/p/fNU3lL-KWn

(Happy to create a different issue if you want to treat this separately)

@robpike, opinions here? Go 1.9, document, do nothing, punt to 1.10?

Punt to 1.10. Also @rsc was the last one to work on that code, although the problems could well be original. Scanf should never have been written. Mea culpa.

Hi,

If anyone is not working on this, may I take this up ?

Also, a question on approaching this - If the appropriate behavior is to return ErrUnexpectedEOF in cases like the ones above, in which cases should we return EOF ?

As far as I understand, EOF is not exactly an error per se. It just signifies that the input has ended. If that is the case, then I believe in all cases where we return EOF, it should be ErrUnexpectedEOF. Let me know what you guys think.

It's trivial. Line 90 returns EOF, reading from a string. Line 928 converts an EOF from an external scanner (here math/big) into ErrUnexpectedEOF. It's inconsistent, yes. Will it break anything to make that change? I don't know. Does it matter? Not really.

It's really not worth fixing. The Scan part of fmt is poorly designed and I would prefer to leave it alone. It's not a good idea to use it. Scan[f] is an idea borrowed from C that's really not a good fit for the Go library.

Perhaps the documentation should be more discouraging.

I still intend to look at this to see if there's a clear fix. The problem is the deciding, not the code.

Sure, let me know what you guys decide. Would be happy to send a CL and reap some commit karma 😝

I also expect io.EOF error

func main() {
	var str string
	n, err := fmt.Sscanf("some (thing)", "some (%s)", &str)
	fmt.Println(n, err) // 1 unexpected EOF
	fmt.Println(str)    // thing)
}