From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38891 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PaY7S-0002dy-K9 for qemu-devel@nongnu.org; Wed, 05 Jan 2011 13:30:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PaY7R-0001xb-IN for qemu-devel@nongnu.org; Wed, 05 Jan 2011 13:29:58 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:39388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PaY7R-0001xV-Eq for qemu-devel@nongnu.org; Wed, 05 Jan 2011 13:29:57 -0500 Received: by vws12 with SMTP id 12so6200342vws.4 for ; Wed, 05 Jan 2011 10:29:56 -0800 (PST) Message-ID: <4D24B8A1.9060801@codemonkey.ws> Date: Wed, 05 Jan 2011 12:29:53 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1294224062-18745-1-git-send-email-Jes.Sorensen@redhat.com> <4D247633.80304@codemonkey.ws> <4D2482D6.2030401@redhat.com> In-Reply-To: <4D2482D6.2030401@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Make strtosz() return int64_t instead of ssize_t List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: agraf@suse.de, qemu-devel@nongnu.org, armbru@redhat.com On 01/05/2011 08:40 AM, Jes Sorensen wrote: > On 01/05/11 14:46, Anthony Liguori wrote: > >> On 01/05/2011 04:41 AM, Jes.Sorensen@redhat.com wrote: >> >>> From: Jes Sorensen >>> >>> strtosz() needs to return a 64 bit type even on 32 bit >>> architectures. Otherwise qemu-img will fail to create disk >>> images>= 2GB >>> >>> Signed-off-by: Jes Sorensen >>> >>> >> off_t would be the proper type to use. >> > I discussed this with Markus, and we both agree that it isn't. > > Two reasons, off_t is for filesystem offsets, not random sizes. Second, > off_t doesn't have an unsigned type or a max to compare against. > That's because the size of off_t depends on whether it's a 32 or 64-bit platform and what FILESIZEBITS is defined to be. Basically, if you're looking for the type to represent offsets in a file, it's off_t. That's why it exists. That said, using this to represent memory too, I can buy that as a justification to use int64_t. > Using int64_t is cleaner and safer. > I wouldn't make such bold claims but I'll concede that one is not significantly better than the other and won't object to int64_t if you feel strongly. Regards, Anthony Liguori > Cheers, > Jes >