From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMJ2i-0000tZ-Al for qemu-devel@nongnu.org; Thu, 21 Jan 2016 12:29:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMJ2f-0000N4-2r for qemu-devel@nongnu.org; Thu, 21 Jan 2016 12:29:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMJ2e-0000Ms-Rl for qemu-devel@nongnu.org; Thu, 21 Jan 2016 12:29:05 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 7576819CF65 for ; Thu, 21 Jan 2016 17:29:04 +0000 (UTC) Date: Thu, 21 Jan 2016 17:29:00 +0000 From: "Daniel P. Berrange" Message-ID: <20160121172900.GQ19835@redhat.com> References: <1453219845-30939-1-git-send-email-eblake@redhat.com> <1453219845-30939-2-git-send-email-eblake@redhat.com> <87si1s1v4u.fsf@blackfin.pond.sub.org> <569FADED.3030307@redhat.com> <87k2n3ihaa.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87k2n3ihaa.fsf@blackfin.pond.sub.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v9 01/37] qobject: Document more shortcomings in our number handling Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: marcandre.lureau@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On Thu, Jan 21, 2016 at 07:21:49AM +0100, Markus Armbruster wrote: > Eric Blake writes: >=20 > > On 01/20/2016 02:02 AM, Markus Armbruster wrote: > > > >>> @@ -519,6 +519,8 @@ static QObject *parse_literal(JSONParserContext= *ctxt) > >>> } > >>> case JSON_FLOAT: > >>> /* FIXME dependent on locale */ > >>> + /* FIXME our lexer matches RFC7159 in forbidding Inf or Na= N, > >>=20 > >> For what it's worth, the RFC spells this "RFC 7159". > > > > Looks like we use space more often than not, but that we're > > inconsistent. For example: > > > > slirp/tcp.h: * Per RFC 793, September, 1981. > > slirp/tcp.h: * Per RFC793, September, 1981. > > > > Will fix if I need to respin, otherwise I assume you can do it. >=20 > Okay. >=20 > >>> + /* FIXME: snprintf() is locale dependent; but JSON require= s > >>> + * numbers to be formatted as if in the C locale. */ > >>=20 > >> The new FIXME matches the existing one in parse_literal(), visible > >> above. > >>=20 > >> However, dependence on C locale is a pervasive issue in QEMU. These= two > >> comments could give readers the idea that it's an issue just here. > >> Suggest to add something like "Dependence on C locale is a pervasive > >> issue in QEMU." > > > > Good idea. > > > >>=20 > >>> + /* FIXME: This risks printing Inf or NaN, which are not va= lid > >>> + * JSON values. */ > >>> + /* FIXME: the default precision of %f may be insufficient = to > >>> + * tell this number apart from others. */ > >>=20 > >> Yup. > >>=20 > >> The easy way to avoid loss of precision is %a, but of course that's = way > >> too much sophistication for JSON. > >>=20 > >> Avoiding loss of precision with a decimal format is non-trivial; see > >> Steele, Jr., Guy L., and White, Jon L. How to print floating-point > >> numbers accurately, SIGPLAN =E2=80=9990, and later improvements coll= ected here: > >> http://stackoverflow.com/questions/7153979/algorithm-to-convert-an-i= eee-754-double-to-a-string > > > > Ah, memories. I read and implemented that paper when working on the > > jikes compiler for the Java language back in the late nineties, as it= is > > the Java language specification which had the very neat property of > > requiring the shortest decimal string that will unambiguously round b= ack > > to the same floating point pattern. > > > > One alternative is to always output a guaranteed unambiguous decimal > > string (although not necessarily the shortest), by using %.17f, using > > DBL_DECIMAL_DIG. (Note that DBL_DIG of 15 is NOT sufficien= t - > > it is the lower limit that says that a decimal->float->decimal will n= ot > > change the decimal; but we want the converse where a > > float->decimal->float will not change the float. There are stretches= of > > numbers where the pigeonhole principle applies; you can think of it t= his > > way: there is no way to map all possible 2^10 (1024) binary values > > inside 2^3 (1000) decimal digits without at least 24 of them needing = one > > more decimal digit. But by the same arguments, DBL_DECIMAL_DIG is an > > upper limit and usually more than you need.) > > > > So, the question is whether we want to always output 17 digits, or > > whether we want to do the poor-man's truncation scheme (easy to > > understand, but not optimal use of the processor), or go all the way = to > > the algorithm of that paper (faster but lots harder to understand). = For > > reference, here's the poor-man's algorithm in pseudocode: >=20 > I don't think we want to implement floating-point formatting ourselves. FWIW in libvirt we use per-thread locale switching, so that we can flip into the C locale temporarily when formatting doubles. If those are not available we have a bit of a nasty hack to post-process the locale dependant string back into what we (hope) is C-locale formatting. We don't do anything aobut the Inf/NaN problem though. http://libvirt.org/git/?p=3Dlibvirt.git;a=3Dblob;f=3Dsrc/util/virutil.c;h= =3Dbb9604a0c1ffb9c99e454e84878a8c376f773046;hb=3DHEAD#l454 Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|