Re: [PATCH v2 11/11] tests/9pfs: add local Tmkdir test

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Oct 02, 2020 at 04:09:53PM +0200, Christian Schoenebeck wrote:
> On Freitag, 2. Oktober 2020 15:44:40 CEST Daniel P. Berrangé wrote:
> > On Fri, Oct 02, 2020 at 03:41:07PM +0200, Christian Schoenebeck wrote:
> > > On Freitag, 2. Oktober 2020 14:56:14 CEST Daniel P. Berrangé wrote:
> > > > On Fri, Oct 02, 2020 at 01:51:54PM +0200, Christian Schoenebeck wrote:
> > > > > This test case uses the 9pfs 'local' driver to create a directory
> > > > > and then checks if the expected directory was actually created
> > > > > (as real directory) on host side.
> > > > > 
> > > > > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > > > > ---
> > > > > 
> > > > >  tests/qtest/virtio-9p-test.c | 139
> > > > >  +++++++++++++++++++++++++++++++++++
> > > > >  1 file changed, 139 insertions(+)
> > > > > 
> > > > > diff --git a/tests/qtest/virtio-9p-test.c
> > > > > b/tests/qtest/virtio-9p-test.c
> > > > > index af7e169d3a..93161a4b35 100644
> > > > > --- a/tests/qtest/virtio-9p-test.c
> > > > > +++ b/tests/qtest/virtio-9p-test.c
> > > > > @@ -18,6 +18,62 @@
> > > > > 
> > > > >  #define QVIRTIO_9P_TIMEOUT_US (10 * 1000 * 1000)
> > > > >  static QGuestAllocator *alloc;
> > > > > 
> > > > > +/*
> > > > > + * Used to auto generate new fids. Start with arbitrary high value to
> > > > > avoid + * collision with hard coded fids in basic test code.
> > > > > + */
> > > > > +static uint32_t fid_generator = 1000;
> > > > > +
> > > > > +static uint32_t genfid(void)
> > > > > +{
> > > > > +    return fid_generator++;
> > > > > +}
> > > > > +
> > > > > +/**
> > > > > + * Splits the @a in string by @a delim into individual (non empty)
> > > > > strings
> > > > > + * and outputs them to @a out. The output array @a out is NULL
> > > > > terminated.
> > > > > + *
> > > > > + * Output array @a out must be freed by calling split_free().
> > > > > + *
> > > > > + * @returns number of individual elements in output array @a out
> > > > > (without
> > > > > the + *          final NULL terminating element)
> > > > > + */
> > > > > +static int split(const char *in, const char *delim, char ***out)
> > > > > +{
> > > > > +    int n = 0, i = 0;
> > > > > +    char *tmp, *p;
> > > > > +
> > > > > +    tmp = g_strdup(in);
> > > > > +    for (p = strtok(tmp, delim); p != NULL; p = strtok(NULL, delim))
> > > > > {
> > > > > +        if (strlen(p) > 0) {
> > > > > +            ++n;
> > > > > +        }
> > > > > +    }
> > > > > +    g_free(tmp);
> > > > > +
> > > > > +    *out = g_malloc0(n * sizeof(char *) + 1); /* last element NULL
> > > > > delimiter */
> > > > 
> > > > Surely this should be  (n + 1) * sizeof(char *), because the last
> > > > element still needs to be large enough to hold a pointer, not a
> > > > single extra byte.
> > > 
> > > Right, good catch!
> > > 
> > > > > +
> > > > > +    tmp = g_strdup(in);
> > > > > +    for (p = strtok(tmp, delim); p != NULL; p = strtok(NULL, delim))
> > > > > {
> > > > > +        if (strlen(p) > 0) {
> > > > > +            (*out)[i++] = g_strdup(p);
> > > > > +        }
> > > > > +    }
> > > > > +    g_free(tmp);
> > > > > +
> > > > > +    return n;
> > > > > +}
> > > > 
> > > > This seems to largely re-invent g_strsplit
> > > > 
> > > > https://developer.gnome.org/glib/2.62/glib-String-Utility-Functions.html
> > > > #g-s trsplit
> > > 
> > > Yes, except that g_strsplit() outputs empty array elements as well. That's
> > > not desired/working for this patch.
> > 
> > Either make the caller ignore/skip over empty elements, or make
> 
> Not an option, since it would create too much test code overhead. I really 
> need [const int elements] and [array without empty elements].
> 
> > this method call g_strsplit and then filter out the empty elements.
> 
> Mmm, so you're suggesting to allocate a new array, copy elements from 
> g_strsplit() array to the new array, and eventually pass that manually 
> allocated array to g_strfreev()? Wouldn't that be a bit unsafe regarding 
> potential future changes in how glib allocates/structures those string arrays?

No need to realloate a new array - just shuffle down the elements in
the array you get back from g_strsplit to discard the empty ones. Sure
the array will end up with a series of NULLs at the end but that is
harmless.

both g_strsplit/g_strfreev work in terms of a normal allocated "char **"
array, so there's no risk of changes to way memory is allocated.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|