From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38392)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@pond.sub.org>) id 1X9HSq-00045S-5k
	for qemu-devel@nongnu.org; Mon, 21 Jul 2014 13:33:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@pond.sub.org>) id 1X9HSh-0002Ad-1M
	for qemu-devel@nongnu.org; Mon, 21 Jul 2014 13:33:28 -0400
Received: from oxygen.pond.sub.org ([2a01:4f8:201:233:1::3]:53351)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@pond.sub.org>) id 1X9HSg-0002AJ-RB
	for qemu-devel@nongnu.org; Mon, 21 Jul 2014 13:33:18 -0400
From: Markus Armbruster <armbru@redhat.com>
References: <1405630053-15052-1-git-send-email-jsnow@redhat.com>
	<87zjg7yyds.fsf@blackfin.pond.sub.org>
	<20140718074623.GC6960@grmbl.mre>
	<87a986vry1.fsf@blackfin.pond.sub.org>
	<20140718112730.GA26614@grmbl.mre>
	<874myesx0m.fsf@blackfin.pond.sub.org>
	<20140718121451.GC26614@grmbl.mre>
	<8761iurenc.fsf@blackfin.pond.sub.org> <53C98E50.2020307@redhat.com>
	<8761irkv8y.fsf@blackfin.pond.sub.org> <53CD355A.1000804@redhat.com>
Date: Mon, 21 Jul 2014 19:33:14 +0200
In-Reply-To: <53CD355A.1000804@redhat.com> (John Snow's message of "Mon, 21
	Jul 2014 11:44:26 -0400")
Message-ID: <87siluaa79.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH v2] virtio-rng: Add human-readable error
	message for negative max-bytes parameter
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: John Snow <jsnow@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>, peter.maydell@linaro.org, qemu-devel@nongnu.org

John Snow <jsnow@redhat.com> writes:

> On 07/21/2014 03:48 AM, Markus Armbruster wrote:
>>
>> It certainly could check whether the value fits into uint64_t.
>>
>> A quick peek at how string-input-visitor.c uses strtoll() makes me
>> cringe.
>>
>> [...]
>
> What I meant by that was to say that by the time a value was returned
> to visit_type_uint64, the value has already been possibly converted
> implicitly from a negative value, and we can't tell at this level if
> that happened without re-inspecting the string we were passed. At that
> point, why not just fix the string parsing mechanics one more layer
> down in parse_type_int() -- or by creating another routine primitive;
> i.e parse_type_uint.
>
> As Eric Blake noted elsewhere in the thread, it would be nice to have
> the ability to have three behaviors at the lowest level -- signed,
> unsigned with wraparound, and unsigned strict. The biggest question in
> my mind is how to add the property flag to allow authors to opt-in to
> the unsigned with wraparound option, where the unsigned strict option
> makes the most sense to me as a default.

Do we have a use case for silently mapping negative numbers to positive
ones?

> For now I will just fix the error message. We can draft ideas for how
> to fix the semantic issues in parsing later.

Yes, that makes sense.