qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 2/5] Support human unit formats in strtobytes, e


From: Paolo Bonzini
Subject: [Qemu-devel] Re: [PATCH 2/5] Support human unit formats in strtobytes, eg. 1.0G
Date: Thu, 16 Sep 2010 09:19:13 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.5

On 09/15/2010 09:31 PM, Jes Sorensen wrote:
On 09/15/10 17:45, Paolo Bonzini wrote:
On 09/15/2010 02:23 PM, address@hidden wrote:
       switch (*endptr++) {
       case 'K':
       case 'k':
           value<<= 10;
           break;
       case 0:
+        if (divider) {
+            value = 0;
+            break;
+        }
       case 'M':
       case 'm':
           value<<= 20;
@@ -284,9 +306,12 @@ uint64_t strtobytes(const char *nptr, char **end)
       default:
           value = 0;
       }
+    if (divider)
+        value /= divider;


This risks overflow if you do 1.00000000000000G or something similarly
braindead.  Do we loathe floating point so much that you cannot use
strtod, like

Floating point is just plain wrong. If someone wants to do something
like in your example they really ask for an error.

An error, not an overflow.

Adding overflow checking on top of your patch is also fine. Another possibility is to look ahead for the multiplier so that you correctly base the divider and do everything in 64.64 fixed point. But it seems overkill compared to floating-point, whose 53-bit mantissa precision will almost always lead to exact results (large numbers usually have a lot of zeros at the end, both in binary and in decimal).

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]