Your code never returns an error. There is nothing for bufio to report.
If you fix your code to actually return errors, it still violates the io.Reader contract:

a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil. The next Read should return 0, EOF

Closing as there is nothing to do.

For questions please refer to https://github.com/golang/go/wiki/Questions

Your code never returns an error. There is nothing for bufio to report.

@seankhliao it does, see line 29

Your Read creates a fresh strings.Reader every time because its defined with a value receiver, and strings.Reader doesn't return an EOF until the second read.

@seankhliao I updated the example code: https://go.dev/play/p/XD0e4msIGqt
you can see that simple io.Copy works, simple io.Copy wrapped around bufio also works, but net/textproto read fails.
Yes, I was wrong with the issue topic, so I renamed it to net/textproto.

Thanks, I do think there is a bug here. net/textproto.Reader.skipSpace assumes that it doesn't have to return the error, with a comment saying "Bufio will keep err until next read.", but that's not how the bufio package works. Once the bufio package has returned an error, it won't return it again.

@ianlancetaylor One quick fix I can think of is to add one more field in bufio's Reader struct to memorize if EOF is reached and let ReadLine() returns while EOF is reached before calling ReadSlice() for the following reasons.

In the case of using a non-autorewind reader, after reading the last line of message with bufio.ReadLine(), there will be one more call on bufio.ReadLine() and the EOF error pops up.

In the case of using autorewind reader, the bufio.ReaderLine() seems to always being able to read something without returning the error and the methods in textproto calling ReadLine() will always read something without receiving the EOF error, making the ReadMIMEHeader() non stop.

Please point out if there anything unclear or unthoughtful above, thanks

The bufio package is pretty low level and it would be much better if we didn't have to change it.

As far as I can see the bug here is in net/textproto, and that is where the fix should occur.

Could I make an attempt at fixing this issue?

Change https://go.dev/cl/418694 mentions this issue: net/textproto: add extra field to indicate whether EOF is reached

Change https://go.dev/cl/421554 mentions this issue: net/textproto: refactor return type of skipSpace function

Change https://go.dev/cl/544935 mentions this issue: net/textproto: improve error handling in skipSpace

Looking again at the original example, the Reader there looks like this:

func (r *autoRewind) Read(p []byte) (int, error) {
	if r.r == nil {
		r.r = strings.NewReader(r.buf)
	}

	n, err := r.r.Read(p)
	fmt.Printf("%d: %v\n", n, err)
	if err == io.EOF {
		// rewind
		r.r = strings.NewReader(r.buf)
	}

	return n, err
}

This is going to return io.EOF and then continue to return data. That violates the io.Reader contract, which says

When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read. It may return the (non-nil) error from the same call or return the error (and n == 0) from a subsequent call. An instance of this general case is that a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil. The next Read should return 0, EOF.

That is, after returning EOF, the Reader should then return 0, EOF. The code in this example does not do that.

So now I'm not sure whether there is a bug here at all.

Thanks for looking this one more time @ianlancetaylor. Re-reading the thread again as well as your last comment, I see what @seankhliao was saying. I agree, the example implementation doesn't do that.