From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: "Warner Losh" <imp@bsdimp.com>,
"Riku Voipio" <riku.voipio@iki.fi>,
"Laurent Vivier" <laurent@vivier.eu>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Kyle Evans" <kevans@freebsd.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v4 1/9] qapi: Make qapi_bool_parse() gracefully handle NULL value
Date: Fri, 10 Jan 2025 13:32:48 +0000 [thread overview]
Message-ID: <Z4EhgEs-V215z34j@redhat.com> (raw)
In-Reply-To: <cf8a0915434ec6c48cf88fffc27a53239cffe34a.camel@linux.ibm.com>
On Fri, Jan 10, 2025 at 02:03:09PM +0100, Ilya Leoshkevich wrote:
> On Fri, 2025-01-10 at 11:33 +0000, Daniel P. Berrangé wrote:
> > On Wed, Jan 08, 2025 at 09:04:56PM +0100, Ilya Leoshkevich wrote:
> > > Use g_strcmp0(), so that NULL is considered an invalid parameter
> > > value.
> >
> > Why are we calling qapi_bool_parse with a NULL value in the first
> > place ? IMHO this is a sign of a bug higher up the call chain
> > that ought to be fixed, as in general all our input parsing code
> > would expect non-NULL input values.
>
> The intended use case is the following (patch 7/9):
>
> g_auto(GStrv) tokens = g_strsplit(*arg, "=", 2);
> Error *err = NULL;
>
> if (g_strcmp0(tokens[0], "suspend") == 0) {
> if (!qapi_bool_parse(tokens[0], tokens[1], &suspend, &err)) {
> warn_report_err(err);
> [...]
>
> The idea is to uniformly handle "suspend=y", "suspend=invalid" and
> "suspend"; the latter requires checking whether token[1] is NULL.
> Of course, this can be special-cased in the caller, but this would be
> less elegant.
On the contrary, I think handling the latter in the caller explicitly
is the correct approach.
As written this code snippet gives readers the misleading impression
that 'tokens[1]' is expected to be a non-NULL bool value. It is not
at all obvious that the code is intentionally trying to support a
NULL value for tokens[1]. Even if we can see that qapi_bool_parse
accepts NULL, a reader has no idea whether this caller has
intentionally passed NULL or simply forgot to raise an error when
NULL is seen.
IMHO this patch should be dropped, and the desired behaviour made
explicit in patch 7.
With 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 :|
next prev parent reply other threads:[~2025-01-10 13:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 20:04 [PATCH v4 0/9] gdbstub: Allow late attachment Ilya Leoshkevich
2025-01-08 20:04 ` [PATCH v4 1/9] qapi: Make qapi_bool_parse() gracefully handle NULL value Ilya Leoshkevich
2025-01-10 11:33 ` Daniel P. Berrangé
2025-01-10 13:03 ` Ilya Leoshkevich
2025-01-10 13:32 ` Daniel P. Berrangé [this message]
2025-01-08 20:04 ` [PATCH v4 2/9] gdbstub: Allow the %d placeholder in the socket path Ilya Leoshkevich
2025-01-08 20:04 ` [PATCH v4 3/9] gdbstub: Try unlinking the unix socket before binding Ilya Leoshkevich
2025-01-08 20:04 ` [PATCH v4 4/9] user: Introduce user/signal.h Ilya Leoshkevich
2025-01-08 20:05 ` [PATCH v4 5/9] user: Introduce host_interrupt_signal Ilya Leoshkevich
2025-01-08 20:05 ` [PATCH v4 6/9] osdep: Introduce qemu_kill_thread() Ilya Leoshkevich
2025-01-08 20:05 ` [PATCH v4 7/9] gdbstub: Allow late attachment Ilya Leoshkevich
2025-01-08 20:05 ` [PATCH v4 8/9] docs/user: Document the %d placeholder and suspend=n QEMU_GDB features Ilya Leoshkevich
2025-01-08 20:05 ` [PATCH v4 9/9] tests/tcg: Add late gdbstub attach test Ilya Leoshkevich
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=Z4EhgEs-V215z34j@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=iii@linux.ibm.com \
--cc=imp@bsdimp.com \
--cc=kevans@freebsd.org \
--cc=laurent@vivier.eu \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=riku.voipio@iki.fi \
/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.