Originally posted by rene
View Post
But maybe it should be, since if you are talking posix, readfile() actualy requires 4 calls: two calls to read, since only a read call returning zero guarantees that you have reached the end of the file. Otherwise, a read call is allowed to return a partial number of bytes (for example if interrupted by a signal). So readfile() would prevent anyone from making that mistake.
But readfile() on Linux (apparently) knows that it just needs one read call based on the internal API and implementation that it uses.
So another advantage of readfile() for apps that read lots, perhaps thousands of (possibly cached) small files or sysfs values is that they can expect that readfile() uses the best internal API for performance and also with the least resource consumption (who knows, maybe avoiding the waste of globally available file descriptors, recycling memory without going through malloc/free, or something else). Even in cases where there is no actual performance advantage, these apps won't need to make measurements to ensure that this is really the case.
EDIT: That is, at least 2 read calls, actually a loop. Even if limiting it to a fixed total (buffer) size, in which case you will need to update the count of remaining space.
Comment