[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/9] QEMU file cleanups
From: |
Juan Quintela |
Subject: |
Re: [PATCH 0/9] QEMU file cleanups |
Date: |
Thu, 04 May 2023 16:56:46 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Peter Xu <peterx@redhat.com> wrote:
> On Thu, May 04, 2023 at 01:38:32PM +0200, Juan Quintela wrote:
>> - convince and review code to see that everything is uint64_t.
>
> One general question to patches regarding this - what's the major benefit
> of using uint64_t?
>
> It doubles the possible numbers to hold, but it's already 64bits so I don't
> think it matters a lot.
We were checking for negatives even when that can't be.
And we are doing this dance of
int64_t x, y;
uint64_t a, b;
x = a;
b = y;
This is always confusing and not always right.
> The thing is we're removing some code trying to
> detect negative which seems to be still helpful to detect e.g. overflows
> (even though I don't think it'll happen). I just still think it's good to
> know when overflow happens, and not sure what I missed on benefits of using
> unsigned here.
If you grep through the code, you see that half of the things are
int64_t and the other half is uint64_t. I find it always confusing.
> I've reviewed all the rest patches and all look good here.
Thanks very much.
- Re: [PATCH 9/9] qemu-file: Account for rate_limit usage on qemu_fflush(), (continued)
[PATCH 3/9] qemu-file: make qemu_file_[sg]et_rate_limit() use an uint64_t, Juan Quintela, 2023/05/04
Re: [PATCH 0/9] QEMU file cleanups, Peter Xu, 2023/05/04
- Re: [PATCH 0/9] QEMU file cleanups,
Juan Quintela <=