Re: [PATCH v2 08/19] cutils: Allow NULL endptr in parse_uint()

[Eric Blake]

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 <eblake@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