This article says `readfile` would return the number of bytes read. It seems like it would be better for it to return the number of bytes in the file, but only write at most `bufsize` bytes into the buffer. That way, if the buffer isn't big enough, you can allocate a correctly-size buffer without needing to `stat` the file. This is how `snprintf` works.
I think some "files" that are actually devices or pipes and stuff, for them the number of bytes in the file doesn't make sense, while bytes read does make sense. That may be why.
That wouldn't work well because you'd need to re-open and seek (or re-read) before continuing.
Ideally readfile would take and return a filefd (default -1); if present, skip the open and just read (closing on EOF). This also fixes the EINTR/SA_RESTART issue loeg[0] raised. From a C perspective, it does have a problem of needing to return multiple values (both a fd and a bytecount), though.
