| Message ID | 1445897165-4842-3-git-send-email-jsnow@redhat.com |
|---|---|
| State | New |
| Headers | show |
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?
On 10/26/2015 04:44 PM, Eric Blake wrote: > 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(-) >> + 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? Uggh. Maybe I should read qemu_strtosz_suffix() before making bogus claims (and assuming that it is merely sugar for strtoll). I stand corrected - the only time you return negative values is if qemu_strtosz_suffx() populated an errno. Reviewed-by: Eric Blake <eblake@redhat.com>
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; } #define EXABYTES(x) ((long long)(x) << 60)
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(-)