From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] qapi: enable use of g_autoptr with QAPI types
Date: Thu, 23 Jul 2020 13:52:11 +0100 [thread overview]
Message-ID: <20200723125211.GI2615312@redhat.com> (raw)
In-Reply-To: <87a6zqgztg.fsf@dusky.pond.sub.org>
On Thu, Jul 23, 2020 at 02:50:51PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Thu, Jul 23, 2020 at 06:49:44AM -0500, Eric Blake wrote:
> >> On 7/23/20 6:12 AM, Daniel P. Berrangé wrote:
> >> > Currently QAPI generates a type and function for free'ing it:
> >> >
> >> > typedef struct QCryptoBlockCreateOptions QCryptoBlockCreateOptions;
> >> > void qapi_free_QCryptoBlockCreateOptions(QCryptoBlockCreateOptions *obj);
> >> >
> >>
> >> > The above code example now becomes
> >> >
> >> > g_autoptr(QCryptoBlockCreateOptions) opts = NULL;
> >> >
> >> > opts = g_new0(QCryptoBlockCreateOptions, 1);
> >> >
> >> > ....do stuff with opts...
> >> >
> >> > Note, if the local pointer needs to live beyond the scope holding the
> >> > variable, then g_steal_pointer can be used. This is useful to return the
> >> > pointer to the caller in the success codepath, while letting it be freed
> >> > in all error codepaths.
> >> >
> >> > return g_steal_pointer(&opts);
> >> >
> >>
> >> Yep, the idea makes sense!
>
> Agree.
>
> >> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> >> > ---
> >> > include/crypto/block.h | 2 --
> >> > scripts/qapi/types.py | 1 +
> >> > 2 files changed, 1 insertion(+), 2 deletions(-)
> >>
> >> Missing a counterpart change to docs/devel/qapi-code-gen.txt.
>
> Yes. Can do that in my tree.
>
> >> And it might
> >> be nice to make this a series with at least one followup patch using the new
> >> capability, or at least so 'make check' coverage. But otherwise on the
> >> right track.
> >
> > The crypto/block.c already makes use of this capability, which is why
> > I had to remove the line from block.h to avoid declaring the same thing
> > twice !
>
> Could be mentioned in the commit message.
>
> Still, using it somewhere in tests would be nice.
> test-qobject-input-visitor.c's test_visitor_in_struct_nested() looks
> trivial to convert. Feel free to pick something else.
Ok, I'll convert some.
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 :|
prev parent reply other threads:[~2020-07-23 12:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 11:12 [PATCH] qapi: enable use of g_autoptr with QAPI types Daniel P. Berrangé
2020-07-23 11:49 ` Eric Blake
2020-07-23 11:56 ` Daniel P. Berrangé
2020-07-23 12:50 ` Markus Armbruster
2020-07-23 12:52 ` Daniel P. Berrangé [this message]
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=20200723125211.GI2615312@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.