On Thu, May 11, 2023 at 09:10:22PM -0500, Eric Blake wrote: > > All the qemu_strto*() functions permit a NULL endptr, just like their > libc counterparts, leaving parse_uint() as the oddball that caused > SEGFAULT on NULL and required the user to call parse_uint_full() > instead. Relax things for consistency, even though the testsuite is > the only impacted caller. Add one more unit test to ensure even > parse_uint_full(NULL, 0, &value) works. This also fixes our code to > uniformly favor EINVAL over ERANGE when both apply. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > --- > tests/unit/test-cutils.c | 18 ++++++++++++++++-- > util/cutils.c | 34 ++++++++++++---------------------- > 2 files changed, 28 insertions(+), 24 deletions(-)
> > @@ -788,28 +793,13 @@ out: > * @base: integer base, between 2 and 36 inclusive, or 0 > * @value: Destination for parsed integer value > * > - * Parse unsigned integer from entire string > + * Parse unsigned integer from entire string, rejecting any trailing slop. > * > - * Have the same behavior of parse_uint(), but with an additional > - * check for additional data after the parsed number. If extra > - * characters are present after a non-overflowing parsed number, the > - * function will return -EINVAL, and *@v will be set to 0. > + * Shorthand for parse_uint(s, NULL, base, value). I'm just now noticing that I also had a nice side effect of removing the reference to *@v when the parameter is actually named value. > */ > int parse_uint_full(const char *s, int base, uint64_t *value) I don't know if there is an easy way to test our doc comments for mismatch from parameter names. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
