On Monday 2024-03-04 14:52, Alejandro Colomar wrote: >> >> which sounds an awful lot like the documented EOVERFLOW behavior: >> >> EOVERFLOW >> count is too large, the operation would result in >> exceeding the maximum size of either the input file or >> the output file. >> >> but the reported error is EINVAL rather than EOVERFLOW. Moreover, the >> (actual) result from this testcase does not go above a few bytes >> anyhow, so should not signal an overflow anyway. > >The kernel detects that offset+count would overflow, and aborts early. >That's actually a good thing. Otherwise, we wouldn't have noticed that >the program is missing an lseek(2) call until much later. >addition of count+offset would cause overflow, that is, undefined >behavior, it's better to not even start. Otherwise, it gets tricky to >write code that doesn't invoke UB. While offset+count would overflow arithmetically, if the file is not larger than SSIZE_MAX, that should be just fine, because sendfile() stops at EOF like read() and does not read beyond EOF or produce extraneous NULs to the point that a huge file position would come about.
