From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TihX1-0005b7-Gr for qemu-devel@nongnu.org; Wed, 12 Dec 2012 03:19:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TihWu-0002iV-2n for qemu-devel@nongnu.org; Wed, 12 Dec 2012 03:19:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TihWt-0002iR-RY for qemu-devel@nongnu.org; Wed, 12 Dec 2012 03:19:00 -0500 Date: Wed, 12 Dec 2012 09:18:44 +0100 From: Stefan Hajnoczi Message-ID: <20121212081844.GA14695@stefanha-thinkpad.redhat.com> References: <1354852190-15095-1-git-send-email-lig.fnst@cn.fujitsu.com> <20121211095241.GC796@stefanha-thinkpad.muc.redhat.com> <1355273897.4650.16.camel@liguang.fnst.cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1355273897.4650.16.camel@liguang.fnst.cn.fujitsu.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [ [PATCH 1/2] cutils:change strtosz_suffix_unit function List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: li guang Cc: kwolf@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org On Wed, Dec 12, 2012 at 08:58:17AM +0800, li guang wrote: > =E5=9C=A8 2012-12-11=E4=BA=8C=E7=9A=84 10:52 +0100=EF=BC=8CStefan Hajno= czi=E5=86=99=E9=81=93=EF=BC=9A > > On Fri, Dec 07, 2012 at 11:49:49AM +0800, liguang wrote: > > > if value to be translated is larger than INT64_MAX, > > > this function will not be convenient for caller to > > > be aware of it, so change a little for this. > > >=20 > > > Signed-off-by: liguang > > > --- > > > cutils.c | 5 +++-- > > > 1 files changed, 3 insertions(+), 2 deletions(-) > >=20 > > I don't understand what this patch is supposed to do. >=20 > little change to let the caller know the translated value overflow Using a negative errno will make the intent clear. > >=20 > > Why change the type of mul from double to int64_t? >=20 > mul is multiplier generated by suffix_mul(return value type int64_t) > so double is incorrect. Okay, thanks. I asked because I wondered whether it had something to do with overflow detection. Please put unrelated changes in separate patches - and if you feel it's not worth putting in a separate patch then maybe it's not worth changing at all. Stefan