From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9FlW-00075B-Ah for qemu-devel@nongnu.org; Mon, 21 Jul 2014 11:44:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9FlO-0005HI-RK for qemu-devel@nongnu.org; Mon, 21 Jul 2014 11:44:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9FlO-0005Gw-It for qemu-devel@nongnu.org; Mon, 21 Jul 2014 11:44:30 -0400 Message-ID: <53CD355A.1000804@redhat.com> Date: Mon, 21 Jul 2014 11:44:26 -0400 From: John Snow MIME-Version: 1.0 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> In-Reply-To: <8761irkv8y.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] virtio-rng: Add human-readable error message for negative max-bytes parameter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Amit Shah , peter.maydell@linaro.org, qemu-devel@nongnu.org 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. For now I will just fix the error message. We can draft ideas for how to fix the semantic issues in parsing later.