On 07/26/2017 05:00 AM, Peter Krempa wrote:
> The callers don't use it so don't waste a strlen(). Also fix the comment
> for the function.
> ---
> tests/testutils.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/tests/testutils.c b/tests/testutils.c
> index ed01136a0..7f1c4672b 100644
> --- a/tests/testutils.c
> +++ b/tests/testutils.c
> @@ -289,9 +289,17 @@ virTestRun(const char *title,
> return ret;
> }
>
> -/* Allocate BUF to the size of FILE. Read FILE into buffer BUF.
> - Upon any failure, diagnose it and return -1, but don't bother trying
> - to preserve errno. Otherwise, return the number of bytes copied into BUF. */
> +
> +/**
> + * virTestLoadFile:
> + * @file: name of the file to load
> + * @buf: buffer to load the file into
> + *
> + * Allocates @buf to the size of FILE. Reads FILE into buffer BUF.
> + * Upon any failure, error is printed to stderr and -1 is returned. 'errno' is
> + * not preserved. On success 0 is returned. Caller is responsible for freeing
> + * @buf.
> + */
Callers that know the file won't contain NUL bytes don't use the
returned length, but if we ever want to parse a file that DOES contain
NUL, then it becomes important. Then again, such a file is that much
more annoying to store in git (it is treated as binary rather than
text), so our testsuite is better off if it avoids files with NUL.
> int
> virTestLoadFile(const char *file, char **buf)
> {
> @@ -345,7 +353,7 @@ virTestLoadFile(const char *file, char **buf)
> }
>
> VIR_FORCE_FCLOSE(fp);
> - return strlen(*buf);
> + return 0;
And really, strlen() is wrong if you have embedded NUL bytes anyways, so
it's pretty certain we weren't relying on a correct length for a file
that contains NUL. So
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list