From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Anand Avati <aavati@redhat.com>,
Vijay Bellur <vbellur@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
Amar Tumballi <amarts@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
bharata@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v7 2/5] sockets: Change inet_parse() to accept address specification without port
Date: Tue, 18 Sep 2012 16:08:43 +0200 [thread overview]
Message-ID: <5058806B.1050307@redhat.com> (raw)
In-Reply-To: <505877CC.4040000@redhat.com>
Am 18.09.2012 15:31, schrieb Paolo Bonzini:
> Il 18/09/2012 15:22, Kevin Wolf ha scritto:
>> Am 17.09.2012 17:23, schrieb Bharata B Rao:
>>> sockets: Change inet_parse() to accept address specification without port
>>>
>>> From: Bharata B Rao <bharata@linux.vnet.ibm.com>
>>>
>>> inet_parse() expects address:port. Change it to work without explicit port
>>> specification. In addition, don't depend solely on the return value of
>>
>> Things like "in addition" in a commit message are almost always a sign
>> that the patch should be split in two.
>>
>>> sscanf but also consider the value obtained for %n directive used in sscanf.
>>> This ensures that the scanning of malformed inet address isn't flagged as
>>> success.
>>
>> Can you give an example string that would be falsely accepted? To me the
>> old checks look fine (even though the new ones are a little bit easier
>> to read, so even if they don't fix anything, they might be worth doing).
>
> "localhost" would fail to be parsed:
>
> - if (2 != sscanf(str,"%64[^:]:%32[^,]%n",addr,port,&pos)) {
> + ret = sscanf(str, "%64[^:]%n:%32[^,]%n", addr, &addr_pos,
> + port, &port_pos);
> + if (addr_pos == -1 || ret == EOF) {
>
> because the : in the format string would not match and sscanf would
> return 1.
Yes, that's the part with making the port optional.
Bharata also claims that "scanning of malformed inet address" could
falsely succeed before, which I can't see (but which I suspect is what
the first two hunks of the patch are meant to address).
> However, is it correct to set the port unconditionally to an empty
> string? Your usecase makes sense, but perhaps the default port be
> passed as an extra parameter to inet_parse instead.
I thought about this, too, but didn't care enough to mention it. Now
that we're two, yes, I'd like adding a default port parameter.
Kevin
next prev parent reply other threads:[~2012-09-18 14:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 15:21 [Qemu-devel] [RFC v7 0/5] GlusterFS support in QEMU - v7 Bharata B Rao
2012-09-17 15:22 ` [Qemu-devel] [PATCH v7 1/5] sockets: Make inet_parse() non static Bharata B Rao
2012-09-18 12:47 ` Kevin Wolf
2012-09-18 12:57 ` Paolo Bonzini
2012-09-20 5:57 ` Bharata B Rao
2012-09-17 15:23 ` [Qemu-devel] [PATCH v7 2/5] sockets: Change inet_parse() to accept address specification without port Bharata B Rao
2012-09-18 13:22 ` Kevin Wolf
2012-09-18 13:31 ` Paolo Bonzini
2012-09-18 14:08 ` Kevin Wolf [this message]
2012-09-20 6:30 ` Bharata B Rao
2012-09-20 6:51 ` Kevin Wolf
2012-09-17 15:24 ` [Qemu-devel] [PATCH v7 3/5] aio: Fix qemu_aio_wait() to maintain correct walking_handlers count Bharata B Rao
2012-09-17 15:25 ` [Qemu-devel] [PATCH v7 4/5] configure: Add a config option for GlusterFS as block backend Bharata B Rao
2012-09-17 15:26 ` [Qemu-devel] [PATCH v7 5/5] block: Support GlusterFS as a QEMU " Bharata B Rao
2012-09-18 14:01 ` Kevin Wolf
2012-09-20 6:41 ` Bharata B Rao
2012-09-20 7:53 ` Paolo Bonzini
2012-09-20 8:20 ` Paolo Bonzini
2012-09-20 9:12 ` Bharata B Rao
2012-09-20 9:14 ` Paolo Bonzini
2012-09-20 9:34 ` Kevin Wolf
2012-09-20 15:08 ` Paolo Bonzini
2012-09-21 3:50 ` Bharata B Rao
2012-09-21 8:23 ` 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=5058806B.1050307@redhat.com \
--to=kwolf@redhat.com \
--cc=aavati@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=amarts@redhat.com \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=vbellur@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 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.