> 'count'  is size_t, like for mmap() and any other function accepting a length, so nothing wrong can happen.

Then why 'offset' and 'count' parameters have a different data type?

Linux: 
sendfile(..., off_t *offset, size_t count);

Solaris:
sendfile(..., off_t *off,    size_t len);

HP-UX:
sendfile(..., off_t offset,  bsize_t nbytes);


> A platform which would have a sendfile prototype which doesn't support
> sending a complete file at once would be completely broken...

You can't send a complete file at once in the first place unless it's very small. 
The usual way to send a file is chunk by chunk, so it wouldn't surprise me if sendfile() prototype does not support the use case you're describing.
Anyway, Antoine's suggestion makes sense to me: it's probably ok to just use a big value and be done with it.
16MB looks a little bit too much to me as the maximum amount of bytes sent per call is a lot less than 1MB, but even then it would probably be ok.


>> It's necessary because sendfile() can fail with EAGAIN.
> It can fail with EAGAIN if the input FD is non-blocking

It will. Try it yourself.


> Furthermore, since sendfile actually supports only regular file and regular 
> files don't support non-blocking I/O, it's unlikely to ever happen.

EAGAIN is caused by the socket fd not being ready yet, not the file fd.
Please try the patch before making such assumptions. We're going OT here.