All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: agraf@suse.de, qemu-devel@nongnu.org, armbru@redhat.com
Subject: [Qemu-devel] Re: [PATCH] Make strtosz() return int64_t instead of ssize_t
Date: Wed, 05 Jan 2011 12:29:53 -0600	[thread overview]
Message-ID: <4D24B8A1.9060801@codemonkey.ws> (raw)
In-Reply-To: <4D2482D6.2030401@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<Jes.Sorensen@redhat.com>
>>>
>>> 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<Jes.Sorensen@redhat.com>
>>>
>>>        
>> 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
>    

  reply	other threads:[~2011-01-05 18:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 10:41 [Qemu-devel] [PATCH] Make strtosz() return int64_t instead of ssize_t Jes.Sorensen
2011-01-05 12:34 ` [Qemu-devel] " Michael S. Tsirkin
2011-01-05 12:36   ` Jes Sorensen
2011-01-05 12:49     ` Michael S. Tsirkin
2011-01-05 13:46 ` Anthony Liguori
2011-01-05 14:40   ` Jes Sorensen
2011-01-05 18:29     ` Anthony Liguori [this message]
2011-01-05 19:30       ` Jes Sorensen
2011-01-11 13:36 ` [Qemu-devel] " Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D24B8A1.9060801@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=Jes.Sorensen@redhat.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.