This is because with the recent changes to make the os package use the runtime poller, the os package has now picked up the special behavior on Read of zero bytes that was formerly restricted to the net package. That behavior is

		// If the caller wanted a zero byte read, return immediately
		// without trying (but after acquiring the readLock).
		// Otherwise syscall.Read returns 0, nil which looks like
		// io.EOF.

The comment is correct unless the descriptor is only opened for writing.

There are couple of ways we could fix this, but I think my first question is: does it really matter? What is the purpose of calling Read(nil)?

Thank you for your answer.
And, sorry. You are right. It doesn't happen in go1.8.

There are couple of ways we could fix this, but I think my first question is: does it really matter? What is the purpose of calling Read(nil)?

My app needs to emulate C's stdio buffer. And current implementation is something like:

type File interface {
	Write(p []byte) (nn int, err error)
	WriteString(s string) (nn int, err error)
	Read(p []byte) (n int, err error)
	ReadByte() (c byte, err error)
        ReadInt() (i int64, err error) // read next token as int64
        ReadFloat() (f float64, err error) // read next token as float64
	ReadBytes(delim byte) (line []byte, err error)
}

// roFile represents a read only file and implements File interface
type roFile struct {
   ...
}

// woFile represents a write only file and implements File interface
type woFile struct {
  ...
}

type rwFile struct {
  ...
}

Then, I need to generate the error for ReadXXX in woFile.
Currently, I am using Read(nil).
I'm Okay to make a workaround. Read([]byte{0}) ?

Read([]byte{0}) will have the side-effect of reading a single byte. I don't know if that is OK for you or not.

You could also simply record in your own data structure whether the file was opened write-only or not. That is what the standard library would have to do to change this. I think the question is whether that needs to be in the standard library or not. We've never really documented the behavior of Read(nil).

You could also simply record in your own data structure whether the file was opened write-only or not. That is what the standard library would have to do to change this.

Unfortunately, I need real system call error messages.
I've already written a workaround hirochachacha/plua@9f77670...fff4918 and it works.

I think the question is whether that needs to be in the standard library or not. We've never really documented the behavior of Read(nil).

I assume the impact is very small. But I'm not sure... Please feel free to close the issue anytime.

Closing. Can reopen if someone else has similar trouble.

Thank you for your responses!