All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu-config: Accept empty option values
Date: Wed, 08 Apr 2015 17:03:20 -0600	[thread overview]
Message-ID: <5525B3B8.40709@redhat.com> (raw)
In-Reply-To: <1428516988-6760-1-git-send-email-ehabkost@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On 04/08/2015 12:16 PM, Eduardo Habkost wrote:
> Currently it is impossible to set an option in a config file to an empty
> string, because the parser matches only lines containing non-empty
> strings between double-quotes.
> 
> As sscanf() "[" conversion specifier only matches non-empty strings, add
> a special case for empty strings.

I avoid sscanf() as a rule (as it's behavior on %d is undefined in the
face of malicious input), so I had to read the man page; but you are
right.  Libvirt is trying to completely ban use of *scanf for that
reason; but obviously qemu is not quite so opposed to it.

> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  util/qemu-config.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/util/qemu-config.c b/util/qemu-config.c
> index 2d32ce7..9f9577d 100644
> --- a/util/qemu-config.c
> +++ b/util/qemu-config.c
> @@ -413,7 +413,8 @@ int qemu_config_parse(FILE *fp, QemuOptsList **lists, const char *fname)
>              opts = qemu_opts_create(list, NULL, 0, &error_abort);
>              continue;
>          }
> -        if (sscanf(line, " %63s = \"%1023[^\"]\"", arg, value) == 2) {
> +        if (sscanf(line, " %63s = \"%1023[^\"]\"", arg, value) == 2 ||
> +            (value[0] = '\0', sscanf(line, " %63s = \"\"", arg) == 1)) {

This is one of the few times I've seen sscanf used in a well-defined
manner (albeit still arbitrarily limiting, in that we have fixed-size
buffers) - but having to rely on a comma operator to get there makes
this look quite arcane.  I still wonder if hand-rolling a real scanner
would beat the compactness of sscanf by making the code intentions a
little more discernible, and have the benefits of avoiding my sscanf
red-flag checker.  But my wonder is not enough to stop me from accepting
this hack as-is.

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2015-04-08 23:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 18:16 [Qemu-devel] [PATCH] qemu-config: Accept empty option values Eduardo Habkost
2015-04-08 23:03 ` Eric Blake [this message]
2015-04-09 12:11 ` Paolo Bonzini
2015-04-09 18:50   ` Eduardo Habkost
2015-04-09 19:11     ` Paolo Bonzini

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=5525B3B8.40709@redhat.com \
    --to=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@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.