From: "Daniel P. Berrange" <berrange@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, lvivier@redhat.com, dgilbert@redhat.com,
peterx@redhat.com
Subject: Re: [Qemu-devel] [PATCH v4 1/2] tests: Use real size for iov tests
Date: Fri, 1 Sep 2017 13:20:21 +0100 [thread overview]
Message-ID: <20170901122021.GN31680@redhat.com> (raw)
In-Reply-To: <20170901115500.12654-2-quintela@redhat.com>
On Fri, Sep 01, 2017 at 01:54:59PM +0200, Juan Quintela wrote:
> We were using -1 instead of the real size because the functions check
> what is bigger, size in bytes or the size of the iov. Recent gcc's
> barf at this.
>
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> Reviewed-by: Peter Xu <peterx@redhat.com>
> Tested-by: Cleber Rosa <crosa@redhat.com>
> --
>
> Remove comments about this feature.
> Fix missing -1.
> ---
> include/qemu/iov.h | 6 ------
> tests/test-iov.c | 10 +++++-----
> 2 files changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/include/qemu/iov.h b/include/qemu/iov.h
> index bd9fd55b0a..72d4c559b4 100644
> --- a/include/qemu/iov.h
> +++ b/include/qemu/iov.h
> @@ -31,11 +31,6 @@ size_t iov_size(const struct iovec *iov, const unsigned int iov_cnt);
> * Number of bytes actually copied will be returned, which is
> * min(bytes, iov_size(iov)-offset)
> * `Offset' must point to the inside of iovec.
> - * It is okay to use very large value for `bytes' since we're
> - * limited by the size of the iovec anyway, provided that the
> - * buffer pointed to by buf has enough space. One possible
> - * such "large" value is -1 (sinice size_t is unsigned),
> - * so specifying `-1' as `bytes' means 'up to the end of iovec'.
> */
> size_t iov_from_buf_full(const struct iovec *iov, unsigned int iov_cnt,
> size_t offset, const void *buf, size_t bytes);
> @@ -76,7 +71,6 @@ iov_to_buf(const struct iovec *iov, const unsigned int iov_cnt,
> * up to the end of it, will be filled with the specified value.
> * Function return actual number of bytes processed, which is
> * min(size, iov_size(iov) - offset).
> - * Again, it is okay to use large value for `bytes' to mean "up to the end".
> */
> size_t iov_memset(const struct iovec *iov, const unsigned int iov_cnt,
> size_t offset, int fillc, size_t bytes);
I'm not sure its right to be removing these comments, unless you've
audited the code to ensure no caller outside the test suite is
relying on this documented behaviour.
> diff --git a/tests/test-iov.c b/tests/test-iov.c
> index fa3d75aee1..458ca25099 100644
> --- a/tests/test-iov.c
> +++ b/tests/test-iov.c
> @@ -81,17 +81,17 @@ static void test_to_from_buf_1(void)
> * skip whole vector and process exactly 0 bytes */
>
> /* first set bytes [i..sz) to some "random" value */
> - n = iov_memset(iov, niov, 0, 0xff, -1);
> + n = iov_memset(iov, niov, 0, 0xff, sz);
> g_assert(n == sz);
>
> /* next copy bytes [i..sz) from ibuf to iovec */
> - n = iov_from_buf(iov, niov, i, ibuf + i, -1);
> + n = iov_from_buf(iov, niov, i, ibuf + i, sz - i);
> g_assert(n == sz - i);
>
> /* clear part of obuf */
> memset(obuf + i, 0, sz - i);
> /* and set this part of obuf to values from iovec */
> - n = iov_to_buf(iov, niov, i, obuf + i, -1);
> + n = iov_to_buf(iov, niov, i, obuf + i, sz - i);
> g_assert(n == sz - i);
>
> /* now compare resulting buffers */
> @@ -109,7 +109,7 @@ static void test_to_from_buf_1(void)
> * with j in [i..sz]. */
>
> /* clear iovec */
> - n = iov_memset(iov, niov, 0, 0xff, -1);
> + n = iov_memset(iov, niov, 0, 0xff, sz);
> g_assert(n == sz);
>
> /* copy bytes [i..j) from ibuf to iovec */
> @@ -225,7 +225,7 @@ static void test_io(void)
> for (i = 0; i <= sz; ++i) {
> for (j = i; j <= sz; ++j) {
> k = i;
> - iov_memset(iov, niov, 0, 0xff, -1);
> + iov_memset(iov, niov, 0, 0xff, sz);
> do {
> s = g_test_rand_int_range(0, j - k + 1);
> r = iov_recv(sv[0], iov, niov, k, s);
For the test-iov.c changes though you can have
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2017-09-01 12:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-01 11:54 [Qemu-devel] [PATCH v4 0/2] Fix tests on recent gcc Juan Quintela
2017-09-01 11:54 ` [Qemu-devel] [PATCH v4 1/2] tests: Use real size for iov tests Juan Quintela
2017-09-01 12:20 ` Daniel P. Berrange [this message]
2017-09-01 15:16 ` Juan Quintela
2017-09-01 11:55 ` [Qemu-devel] [PATCH v4 2/2] tests: Make vmgenid test compile Juan Quintela
2017-09-01 12:18 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170901122021.GN31680@redhat.com \
--to=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=lvivier@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.