tags 630029 fixed-upstream thanks And here's the documentation fix.
Thanks, Michael diff --git a/man2/pread.2 b/man2/pread.2 index de1e951..c7a7fdd 100644 --- a/man2/pread.2 +++ b/man2/pread.2 @@ -85,6 +85,12 @@ and .BR pwrite () returns the number of bytes written. +Note that is not an error for a successful call to transfer fewer bytes +than requested (see +.BR read (2) +and +.BR write (2)). + On error, \-1 is returned and .I errno is set to indicate the cause of the error. diff --git a/man2/read.2 b/man2/read.2 index 62d7d8b..c581f72 100644 --- a/man2/read.2 +++ b/man2/read.2 @@ -87,6 +87,8 @@ available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because .BR read () was interrupted by a signal. +See also NOTES. + On error, \-1 is returned, and .I errno is set appropriately. @@ -178,6 +180,14 @@ or to return the number of bytes already read. .SH CONFORMING TO SVr4, 4.3BSD, POSIX.1-2001. .SH NOTES +On Linux, +.BR read () +(and similar system calls) will transfer at most +0x7ffff000 (2,147,479,552) bytes, +returning the number of bytes actually transferred. +.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69 +(This is true on both 32-bit and 64-bit systems.) + On NFS filesystems, reading small amounts of data will update the timestamp only the first time, subsequent calls may not do so. This is caused diff --git a/man2/readv.2 b/man2/readv.2 index 3cc0813..3cf0c2f 100644 --- a/man2/readv.2 +++ b/man2/readv.2 @@ -184,6 +184,13 @@ return the number of bytes read; and .BR pwritev () return the number of bytes written. + +Note that is not an error for a successful call to transfer fewer bytes +than requested (see +.BR read (2) +and +.BR write (2)). + On error, \-1 is returned, and \fIerrno\fP is set appropriately. .SH ERRORS The errors are as given for diff --git a/man2/sendfile.2 b/man2/sendfile.2 index 972564c..ef9ba6c 100644 --- a/man2/sendfile.2 +++ b/man2/sendfile.2 @@ -113,6 +113,7 @@ Note that a successful call to .BR sendfile () may write fewer bytes than requested; the caller should be prepared to retry the call if there were unsent bytes. +See also NOTES. On error, \-1 is returned, and .I errno @@ -166,6 +167,12 @@ Other UNIX systems implement with different semantics and prototypes. It should not be used in portable programs. .SH NOTES +.BR sendfile () +will transfer at most 0x7ffff000 (2,147,479,552) bytes, +returning the number of bytes actually transferred. +.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69 +(This is true on both 32-bit and 64-bit systems.) + If you plan to use .BR sendfile () for sending files to a TCP socket, but need diff --git a/man2/write.2 b/man2/write.2 index 90ef9b5..3e8c363 100644 --- a/man2/write.2 +++ b/man2/write.2 @@ -89,6 +89,10 @@ Note that not all filesystems are POSIX conforming. .SH RETURN VALUE On success, the number of bytes written is returned (zero indicates nothing was written). +It is not an error if this number is smaller than the number of bytes +requested; this may happen for example because the disk device was filled. +See also NOTES. + On error, \-1 is returned, and \fIerrno\fP is set appropriately. @@ -217,6 +221,14 @@ then the call fails with the error .BR EINTR ; if it is interrupted after at least one byte has been written, the call succeeds, and returns the number of bytes written. + +On Linux, +.BR read () +(and similar system calls) will transfer at most +0x7ffff000 (2,147,479,552) bytes, +returning the number of bytes actually transferred. +.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69 +(This is true on both 32-bit and 64-bit systems.) .SH BUGS According to POSIX.1-2008/SUSv4 Section XSI 2.9.7 ("Thread Interactions with Regular File Operations"): -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org