From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: Greg Kurz <groug@kaod.org>
Cc: qemu-devel@nongnu.org, Laurent Vivier <lvivier@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Huth <thuth@redhat.com>
Subject: Re: [PATCH] tests/9pfs: Use g_autofree and g_autoptr where possible
Date: Mon, 31 Jan 2022 16:12:45 +0100 [thread overview]
Message-ID: <2777753.eeY9lOXx2E@silver> (raw)
In-Reply-To: <20220131154408.4b9fab8e@bahia>
On Montag, 31. Januar 2022 15:44:46 CET Greg Kurz wrote:
> On Mon, 31 Jan 2022 13:37:23 +0100
>
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Montag, 31. Januar 2022 08:35:24 CET Greg Kurz wrote:
> > > > > > diff --git a/tests/qtest/libqos/virtio-9p.c
> > > > > > b/tests/qtest/libqos/virtio-9p.c index ef96ef006adc..0a0d0d16709b
> > > > > > 100644
> > > > > > --- a/tests/qtest/libqos/virtio-9p.c
> > > > > > +++ b/tests/qtest/libqos/virtio-9p.c
> > > > > > @@ -40,14 +40,13 @@ static char *concat_path(const char* a, const
> > > > > > char* b)
> > > > > >
> > > > > > void virtio_9p_create_local_test_dir(void)
> > > > > > {
> > > > > >
> > > > > > struct stat st;
> > > > > >
> > > > > > - char *pwd = g_get_current_dir();
> > > > > > - char *template = concat_path(pwd, "qtest-9p-local-XXXXXX");
> > > > > > + g_autofree char *pwd = g_get_current_dir();
> > > > > > + g_autofree char *template = concat_path(pwd,
> > > > > > "qtest-9p-local-XXXXXX");
> > > > > >
> > > > > > local_test_path = mkdtemp(template);
> > > >
> > > > ... mkdtemp() does not allocate a new buffer, it just modifies the
> > > > character array passed, i.e. the address returned by mkdtemp() equals
> > > > the
> > > > address of variable 'template', and when
> > > > virtio_9p_create_local_test_dir() scope is left, the global variable
> > > > 'local_test_path' would then point to freed memory.
> > >
> > > I hate global variables ;-) and the 'Returned result must be freed'
> > > comment
> > > in 'concat_path()' is slightly misleading in this respect.
> >
> > About the global variable: sure, I am not happy about it either. What I
> > disliked even more is that virtio_9p_create_local_test_dir() is called
> > from a constructor, but as I described in [1] I did not find a realiable
> > alternative. If somebody comes up with a working and reliable, clean
> > alternative, very much appreciated!
>
> An alternative might be to create/remove the test directory when
> a virtio-9p device is started/destroyed, and keeping the string
> under the QVirtio9p structure.
Yeah, I tried that already. Keep in mind it not only has to work sometimes, it
has to work reliably, always, for everybody and commit history shows that this
can be more hairy than one might think and observe.
> The most notable effect would be
> to have a new directory for each individual test instead of
> all the lifetime of qos-test, but it doesn't hurt. I'll have a look.
I'd like to avoid just converting one compromise into another one.
If I had to choose between fixing a purely theoretical issue of getting rid of
a global variable, or introducing a real-life issue in form of numerous new
test dirs popping up on toplevel, I rather stick to the former. We already
have enough test dirs popping up on toplevel IMO.
A truly clean solution for this would be the introduction of setup/teardown
callback pairs in libqos, like it is standard in other test suites. No plans
on my side for spending coding time on that in near future though. My review
time for patches on that being assured though.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2022-01-31 15:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 17:11 [PATCH] tests/9pfs: Use g_autofree and g_autoptr where possible Greg Kurz
2022-01-27 7:57 ` Thomas Huth
2022-01-28 11:49 ` Christian Schoenebeck
2022-01-29 12:33 ` Christian Schoenebeck
2022-01-31 7:35 ` Greg Kurz
2022-01-31 12:37 ` Christian Schoenebeck
2022-01-31 14:44 ` Greg Kurz
2022-01-31 15:12 ` Christian Schoenebeck [this message]
2022-01-31 16:09 ` Greg Kurz
2022-01-31 16:18 ` Christian Schoenebeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2777753.eeY9lOXx2E@silver \
--to=qemu_oss@crudebyte.com \
--cc=groug@kaod.org \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).