From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NAO2h-0007yp-Uz
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:24:24 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NAO2d-0007tI-0W
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:24:23 -0500
Received: from [199.232.76.173] (port=38578 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NAO2c-0007st-RT
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:24:18 -0500
Received: from mx20.gnu.org ([199.232.41.8]:1982)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1NAO2c-0002Y0-F8
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:24:18 -0500
Received: from mail.codesourcery.com ([38.113.113.100])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1NAO2b-0001Jc-EU
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:24:17 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] OPT_SIZE parsing
Date: Tue, 17 Nov 2009 13:24:14 +0000
References: <4B029916.6000809@collabora.co.uk>
In-Reply-To: <4B029916.6000809@collabora.co.uk>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200911171324.15230.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Ian Molton <ian.molton@collabora.co.uk>

On Tuesday 17 November 2009, Ian Molton wrote:
> Hi,
> 
> Qemu currently is making a bit of a hash of parsing suffixes,
> 
> Right now, it has:
> 
> T, G, M, and K  which are multiples of 1024 bytes - fair enough
> 
> but it also has:
> 
> k - 1024  (should be 1000)
> 
> and b:
> 
> Byte (also wrong)
> 
> since its only using a single character, with b taken, theres no way to
> represent 'bit' unless I use B, which is a bit, well daft.
> 
> Would there be any issues if this was updated to parse
> [T,t,G,g,M,m,K,k,][,B,b] type syntax, so we could have things like Kb
> and MB for Kbits and Megabytes respectively ?

When do we ever have a value that can be specified as both bits and bytes? I 
don't think it makes sense to specify this. The fact that we accept a "b" 
suffix at all is suspicious.
For the magnitude IMO only sane thing to do is ignore the case, and decide 
whether we're using binary or decimal multipliers. Remember that if you're 
being pedantic then "m" should be 0.001.

Paul