While it's certainly just example code, the initial sendfile version is badly buggy. /* Fall back to traditional copy if the spliced version fails. */ i

While it's certainly just example code, the initial sendfile version is badly buggy. /* Fall back to traditional copy if the spliced version fails. */ if (!spliced_copy(srcfd)) copy(srcfd); The thing that they are trying to avoid is sendfile failing due to inability to mmap the the fd. But they don't check for that (it would return EINVAL), and in fact, by converting the error code to boolean, destroy the ability to differentiate[1]. Instead, they check that sendfile failed for any reason, and then redo it with copy. Which means sendfile could output half the data, fail for some reason, and depending on why it failed, the fallback copy read/write will do bad things. for example, output the same data again, or more likely, skip data. Since they are just reading from the fd as it now exists after sendfile failing, it is most likely to skip data but pretend it completed successfully. Normally, cat would just fail in that situation, as this should - it should not retry the copy when sendfile returns EINVAL or ENOSYS This is what you get for transforming error codes into booleans :) (I guess errno will still be set, and they could still check it here, but ugh) [1] This is why the man page says: Applications may wish to fall back to read(2)/write(2) in the case where sendfile() fails with EINVAL or ENOSYS.