From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, "Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [RFC PATCH-for-5.2 0/5] qom: Let ObjectPropertyGet functions return a boolean value
Date: Thu, 16 Jul 2020 10:25:33 +0200 [thread overview]
Message-ID: <87sgdrrhmq.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200715175835.27744-1-philmd@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Wed, 15 Jul 2020 19:58:30 +0200")
Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> RFC series to follow Markus direction to simplify error
> propagation. Not sure it is worth it yet. It starts to
> be interesting when using the QEMU_WARN_UNUSED_RESULT
> attribute in the visitors, such:
>
> -- >8 --
> @@ -525,6 +533,7 @@ bool visit_type_uint8(Visitor *v, const char *name, uint8_t *obj,
> * Visit a uint16_t value.
> * Like visit_type_int(), except clamps the value to uint16_t range.
> */
> +QEMU_WARN_UNUSED_RESULT
> bool visit_type_uint16(Visitor *v, const char *name, uint16_t *obj,
> Error **errp);
QEMU_WARN_UNUSED_RESULT is problematic with functions taking an Error **
argument, because using &error_abort or &error_fatal the intended way
triggers the warning.
Does that make &error_abort and &error_fatal bad ideas? They do help
keeping the code concise in places... Hundreds of places, according to
git-grep.
> ---
>
> But to get there we need to update the QAPI generators first :)
prev parent reply other threads:[~2020-07-16 8:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 17:58 [RFC PATCH-for-5.2 0/5] qom: Let ObjectPropertyGet functions return a boolean value Philippe Mathieu-Daudé
2020-07-15 17:58 ` [PATCH-for-5.2 1/5] hw/core/qdev-properties: Simplify get_reserved_region() Philippe Mathieu-Daudé
2020-07-16 8:29 ` Markus Armbruster
2020-07-16 8:38 ` Philippe Mathieu-Daudé
2020-07-16 9:36 ` Markus Armbruster
2020-07-15 17:58 ` [RFC PATCH-for-5.2 2/5] qom: Split ObjectPropertyAccessor as ObjectProperty[Get/Set] Philippe Mathieu-Daudé
2020-07-15 17:58 ` [PATCH-for-5.2 3/5] qom: Use g_autofree in ObjectPropertyGet functions Philippe Mathieu-Daudé
2020-07-15 17:58 ` [RFC PATCH-for-5.2 4/5] qom: Let ObjectPropertyGet functions return a boolean value Philippe Mathieu-Daudé
2020-07-16 9:07 ` Markus Armbruster
2020-09-07 14:26 ` Markus Armbruster
2020-09-07 14:36 ` Peter Maydell
2020-09-07 14:36 ` Philippe Mathieu-Daudé
2020-07-15 17:58 ` [RFC PATCH-for-5.2 5/5] hw/virtio: Simplify virtio_mem_set_requested_size() Philippe Mathieu-Daudé
2020-07-16 9:14 ` Markus Armbruster
2020-07-16 8:25 ` Markus Armbruster [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=87sgdrrhmq.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.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.