Behaviour of io.ReadAt() at the end of input source

I have a program that constantly reads bytes of a input file, in 1MB ranges, after initially splitting the file into multiples of this ranges, i.e. 'n' window ranges. The source file is of type *os.File and I use ReadAt method from the io package to read at the specific start address of each window.

The problem is, when reading towards the end of the file, e.g. in the last window, though the file is still within the range, I get EOF errors. When I looked up the go.dev documentation for the same, it says

> If the n = len(p) bytes returned by ReadAt are at the end of the input source, ReadAt may return either err == EOF or err == nil.

It is not clear, under what circumstances it would return nil, because I keep getting EOF, even when I'm still reading within the range. Why does this happen and how to avoid this situation?

Or I should use io.SectionReader for this case?

Not able to produce a MCVE for this scenario. Apologies!

> If the n = len(p) bytes returned by ReadAt are at the end of the input source, ReadAt may return either err == EOF or err == nil.

This quote relates to the ReaderAt.ReadAt() method:

ReadAt(p []byte, off int64) (n int, err error)

You pass a slice to read into, and an offset to read at (from). The method returns the number of read bytes and an error. The quoted part means if the passed slice is fully read and this operation exhausted the input (meaning the end is reached), err may be nil or may be io.EOF. This is implementation dependant, you should write code that does not depend on what a concrete implementation returns.

In practice this means if io.EOF is returned, you know right away there are no more inputs. If n == len(p) and err == nil, this just means you don't know yet whether there are more data to read or not, you have to call Read() or ReadAt() again, which will read 0 bytes (n == 0) if there are no more data, and this time err will surely be io.EOF (given no other error occurs).

Documentation of ReaderAt.ReadAt() also states that:

> When ReadAt returns n < len(p), it returns a non-nil error explaining why more bytes were not returned. In this respect, ReadAt is stricter than Read.

This means if ReadAt() can't fill p completely from the source (e.g. because its end is reached before len(p) bytes could've been read), ReadAt() will return a non-nil error which will be io.EOF (if the cause is that the end of source was reached).

As this second quote states: ReadAt() is stricter than Read(), ReadAt() will try to fill the passed slice (similar to io.ReadFull()). So you should only use io.SectionReader if it makes your code more readable or it gives you convenience (e.g. if you do not want a 1 MB buffer to read that part in one step, io.SectionReader may make that code simpler), otherwise it won't give you much.