aboutsummaryrefslogtreecommitdiff
path: root/qemu-img.c
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2018-12-15 07:53:10 -0600
committerEric Blake <eblake@redhat.com>2019-01-05 07:53:22 -0600
commitef2e35fcc8e14bcc9366df5fdf53f65d679f8dca (patch)
tree9566fc73deb06530ce8ef5207748ea2ba3c40f82 /qemu-img.c
parent3c1fa35d74aabe9c3ab642d2591b087e53d7a616 (diff)
downloadqemu-ef2e35fcc8e14bcc9366df5fdf53f65d679f8dca.zip
qemu-ef2e35fcc8e14bcc9366df5fdf53f65d679f8dca.tar.gz
qemu-ef2e35fcc8e14bcc9366df5fdf53f65d679f8dca.tar.bz2
nbd/client: Drop pointless buf variable
There's no need to read into a temporary buffer (oversized since commit 7d3123e1) followed by a byteswap into a uint64_t to check for a magic number via memcmp(), when the code immediately below demonstrates reading into the uint64_t then byteswapping in place and checking for a magic number via integer math. What's more, having a different error message when the server's first reply byte is 0 is unusual - it's no different from any other wrong magic number, and we already detected short reads. That whole strlen() issue has been present and useless since commit 1d45f8b5 in 2010; perhaps it was leftover debugging (since the correct magic number happens to be ASCII)? Make the error messages more consistent and detailed while touching things. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20181215135324.152629-9-eblake@redhat.com>
Diffstat (limited to 'qemu-img.c')
0 files changed, 0 insertions, 0 deletions