On Fri, 5 May 2017 11:55:43 -0500 Eric Blake <ebl...@redhat.com> 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 <gr...@kaod.org> > > --- > > 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 <ebl...@redhat.com> >
pgpE23toocmkD.pgp
Description: OpenPGP digital signature