From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59F9DC432C3 for ; Tue, 26 Nov 2019 08:52:44 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 21AB820722 for ; Tue, 26 Nov 2019 08:52:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21AB820722 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:51556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZWaR-0007pv-9o for qemu-devel@archiver.kernel.org; Tue, 26 Nov 2019 03:52:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47679) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZWTs-0000Wx-B5 for qemu-devel@nongnu.org; Tue, 26 Nov 2019 03:45:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZWGW-0004sk-FD for qemu-devel@nongnu.org; Tue, 26 Nov 2019 03:32:09 -0500 Received: from mga17.intel.com ([192.55.52.151]:38283) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iZWGW-0004pc-5Y for qemu-devel@nongnu.org; Tue, 26 Nov 2019 03:32:08 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Nov 2019 00:31:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,245,1571727600"; d="scan'208";a="220558780" Received: from txu2-mobl.ccr.corp.intel.com (HELO [10.239.197.13]) ([10.239.197.13]) by orsmga002.jf.intel.com with ESMTP; 26 Nov 2019 00:31:57 -0800 Subject: Re: [PATCH v17 02/14] util/cutils: Use qemu_strtold_finite to parse size To: Markus Armbruster References: <20191122074826.1373-1-tao3.xu@intel.com> <20191122074826.1373-3-tao3.xu@intel.com> <87tv6sjvfi.fsf@dusky.pond.sub.org> From: Tao Xu Message-ID: Date: Tue, 26 Nov 2019 16:31:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <87tv6sjvfi.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.151 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "lvivier@redhat.com" , "thuth@redhat.com" , "ehabkost@redhat.com" , "mst@redhat.com" , "jonathan.cameron@huawei.com" , "sw@weilnetz.de" , "Du, Fan" , "mdroth@linux.vnet.ibm.com" , "qemu-devel@nongnu.org" , "Liu, Jingqi" , "imammedo@redhat.com" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 11/25/2019 2:56 PM, Markus Armbruster wrote: > Tao Xu writes: > >> Support full 64bit precision, modify related test cases. > > That's not true in general: long double need not be any wider than > double. > > It might be true on the host machines we support, but I don't know. If > we decide to rely on it, we better make the build fail when the host > machine doesn't meet our expectations, preferably in configure. > [...] >> - if ((val * mul >= 0xfffffffffffffc00) || val < 0) { >> + /* Values > UINT64_MAX overflow uint64_t */ >> + if ((val * mul > UINT64_MAX) || val < 0) { >> retval = -ERANGE; >> goto out; >> } > > Not portable. If it was, we'd have made this changd long ago :) > OK. So the suitable solution is what you suggested in v14? "A possible alternative is to parse the numeric part both as a double and as a 64 bit unsigned integer, then use whatever consumes more characters. This enables providing full 64 bits unless you actually use a fraction." I will try this way.