util: Use unsigned (size_t) value for iov length
The "correct" type for the length of an IOV is unclear: writev() and readv() use an int, but sendmsg() and recvmsg() use a size_t. Using the unsigned size_t has some advantages, though, and it makes more sense for the case of write_remainder. Using size_t throughout here means we don't have a signed vs. unsigned comparison, and we don't have to deal with the case of iov_skip_bytes() returning a value which becomes negative when assigned to an integer. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This commit is contained in:
parent
e877f905e5
commit
031df332e9
2 changed files with 3 additions and 4 deletions
5
util.c
5
util.c
|
@ -592,10 +592,9 @@ int do_clone(int (*fn)(void *), char *stack_area, size_t stack_size, int flags,
|
||||||
*
|
*
|
||||||
* #syscalls write writev
|
* #syscalls write writev
|
||||||
*/
|
*/
|
||||||
int write_remainder(int fd, const struct iovec *iov, int iovcnt, size_t skip)
|
int write_remainder(int fd, const struct iovec *iov, size_t iovcnt, size_t skip)
|
||||||
{
|
{
|
||||||
int i;
|
size_t offset, i;
|
||||||
size_t offset;
|
|
||||||
|
|
||||||
while ((i = iov_skip_bytes(iov, iovcnt, skip, &offset)) < iovcnt) {
|
while ((i = iov_skip_bytes(iov, iovcnt, skip, &offset)) < iovcnt) {
|
||||||
ssize_t rc;
|
ssize_t rc;
|
||||||
|
|
2
util.h
2
util.h
|
@ -182,7 +182,7 @@ void pidfile_write(int fd, pid_t pid);
|
||||||
int __daemon(int pidfile_fd, int devnull_fd);
|
int __daemon(int pidfile_fd, int devnull_fd);
|
||||||
int fls(unsigned long x);
|
int fls(unsigned long x);
|
||||||
int write_file(const char *path, const char *buf);
|
int write_file(const char *path, const char *buf);
|
||||||
int write_remainder(int fd, const struct iovec *iov, int iovcnt, size_t skip);
|
int write_remainder(int fd, const struct iovec *iov, size_t iovcnt, size_t skip);
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* af_name() - Return name of an address family
|
* af_name() - Return name of an address family
|
||||||
|
|
Loading…
Reference in a new issue