The write system call prototype is:
ssize_t write(int fd, const void *buf, size_t count);
The count parameter is unsigned, and the return value is signed.
The help page says:
On success, the number of bytes written is returned (zero indicates nothing was written).
On error, -1 is returned, and errno
is set appropriately.
However, it doesn't say what is the limit to the count parameter.
It still doesn't say the behavior when count is greater than SSIZE_MAX
.
Considering write is a system call that can be used to generic devices/files/whatever, if the device supports write operations bigger than SSIZE_MAX, the returning type can't handle the real number of bytes writen.
Doesn't make sense to me to be able to pass an unsigned number of bytes and get back an signed number of bytes as a result. Why not just pass an signed number?
It feels like the prototype of the write function in sort of error prone, or at least it leaves a possible hole in the path.
Does anyone knows the details about it or where can I find this information?
The write is one of the most basic routines provided by a Unix-like operating system kernel. It writes data from a buffer declared by the user to a given device, such as a file. This is the primary way to output data from a program by directly using a system call. The destination is identified by a numeric code.
The write() function shall attempt to write nbyte bytes from the buffer pointed to by buf to the file associated with the open file descriptor, fildes. Before any action described below is taken, and if nbyte is zero and the file is a regular file, the write() function may detect and return errors as described below.
On success, the number of bytes written are returned (zero indicates nothing was written). On error, -1 is returned, and errno is set appropriately. If count is zero and the file descriptor refers to a regular file, 0 may be returned, or an error could be detected. For a special file, the results are not portable.
No, it only blocks the process until the content of the buffer is copied to kernel space.
I don't think there is a hard limit, it depends on what fd
points to. If it's a file on the filesystem for instance, then the file system driver will choke if you exceed the "max file size limit", returning EFBIG error:
EFBIG An attempt was made to write a file that exceeds the implementation- defined maximum file size or the process file size limit.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With