fix: file read - offset and length checks

[rinor]

resolve #2091

[francescolavra]

There is a bug that affects both reads and writes when the offset is greater than the file length; at least for the read part, it is caused by

nanos/src/unix/syscall.c

Line 455 in 26ee8dc

len = file_len - r.start;

, and I think it should be fixed by changing the file_io_complete() function so that it avoids adjusting the return value when 0 bytes have been read, e.g. by changing the preceding if () condition to something like if ((len > 0) && (r.start + len > file_len)). I'm not sure that would fix the write issue too, though.

[rinor]

well writes are a bit weird and would argue that nanos is more posix compliant than linux (bug) when it comes to pwrite64.

From https://www.man7.org/linux/man-pages/man2/pwrite.2.html :
Bugs
POSIX requires that opening a file with the O_APPEND flag should have no effect on the location at which pwrite() writes data. However, on Linux, if a file is opened with O_APPEND, pwrite() appends data to the end of the file, regardless of the value of offset.

that means that right now this works the same on both nanos/linux alowing you to seek and fill the "gaps" with 0x00

file, err := os.OpenFile(fileName, os.O_RDWR|os.O_CREATE, 0666)
offset := fileInfo.Size() + 1 // put offset outside file length
n, err = syscall.Pwrite(int(file.Fd()), []byte("12345"), offset)

but this one behaves different, on nanos behaves like the POSIX expects, but on Linux offset is not taken in consideration and data is just appended to the end of file without "gaps"

file, err := os.OpenFile(fileName, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
offset := fileInfo.Size() + 1 // put offset outside file length
n, err = syscall.Pwrite(int(file.Fd()), []byte("12345"), offset)

Is this what you are referring to about writes?

There is a bug that affects both reads and writes when the offset is greater than the file length;

[francescolavra]

Sorry, somehow I was under the impression that pwrite() was suffering from the same bug as pread(), but I checked better now and that's not the case, so pwrite() is fine as it is.
I have just 2 trivial comments on the changes for fixing pread().