[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/5] 9pfs: check return value of v9fs_co_name_to
From: |
Greg Kurz |
Subject: |
Re: [Qemu-devel] [PATCH 1/5] 9pfs: check return value of v9fs_co_name_to_path() |
Date: |
Fri, 5 May 2017 19:30:46 +0200 |
On Fri, 5 May 2017 11:55:43 -0500
Eric Blake <address@hidden> wrote:
> On 05/05/2017 09:37 AM, Greg Kurz wrote:
> > These v9fs_co_name_to_path() call sites have always been around. I guess
> > no care was taken to check the return value because the name_to_path
> > operation could never fail at the time. This is no longer true: the
> > handle and synth backends can already fail this operation, and so will the
> > local backend soon.
> >
> > Signed-off-by: Greg Kurz <address@hidden>
> > ---
> > hw/9pfs/9p.c | 36 +++++++++++++++++++++++++-----------
> > 1 file changed, 25 insertions(+), 11 deletions(-)
> >
>
> > @@ -2588,8 +2591,11 @@ static int coroutine_fn v9fs_complete_rename(V9fsPDU
> > *pdu, V9fsFidState *fidp,
> > new_name = g_malloc0(end - old_name + name->size + 1);
> > strncat(new_name, old_name, end - old_name);
> > strncat(new_name + (end - old_name), name->data, name->size);
>
> Ad long as you're here, you could replace this strncat mess with the
> shorter:
>
> new_name = g_strdup_printf("%.*s%.*s", end - old_name, old_name,
> name->size, name->data);
>
> (or with further simplifications if you have NUL-terminated data). But
> that can be a separate cleanup.
>
Yes you're right, this definitely looks better than the strncat() logic.
I guess I'll do this in a separate patch.
Thanks for the suggestion.
> Reviewed-by: Eric Blake <address@hidden>
>
pgpKgkzCDD7vT.pgp
Description: OpenPGP digital signature
[Qemu-devel] [PATCH 3/5] 9pfs: local: simplify file opening, Greg Kurz, 2017/05/05