Re: [Qemu-devel] [PATCH 2/3] qemu-io: Check for trailing chars

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On 10/26/2015 04:06 PM, John Snow wrote:
> Make sure there's not trailing garbage, e.g.
> "64k-whatever-i-want-here"
> 
> Reported-by: Max Reitz <mreitz@redhat.com>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
>  qemu-io-cmds.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 

> diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
> index 07c5681..e2477fc 100644
> --- a/qemu-io-cmds.c
> +++ b/qemu-io-cmds.c
> @@ -136,7 +136,14 @@ static char **breakline(char *input, int *count)
>  static int64_t cvtnum(const char *s)
>  {
>      char *end;
> -    return qemu_strtosz_suffix(s, &end, QEMU_STRTOSZ_DEFSUFFIX_B);
> +    int64_t ret;
> +
> +    ret = qemu_strtosz_suffix(s, &end, QEMU_STRTOSZ_DEFSUFFIX_B);
> +    if (*end != '\0') {
> +        /* Detritus at the end of the string */
> +        return -EINVAL;
> +    }
> +    return ret;
>  }

Eww.  This mixes up two return types, negative errno, and negative
input.  User input of -22 shouldn't behave differently than -21, just
because it happens to match -EINVAL.

Do we ever want to allow a negative return from cvtnum(), or should we
just blindly map a negative int64_t into -ERANGE for a contract that we
only accept 63-bit numbers?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]