On Sat, Nov 11, 2017 at 08:39:11AM -0800, Elijah Newren wrote:
> Thanks for pointing out unsigned_mult_overflows; I was unaware of it.
> I think I'd prefer to not use it though; the fact that I had a case
> that genuinely needed a value greater than 2^31 (at least before my
> performance patches) m
Hi,
On Fri, Nov 10, 2017 at 3:42 PM, brian m. carlson
wrote:
> On Fri, Nov 10, 2017 at 10:36:17AM -0800, Elijah Newren wrote:
>> Further, the later patch used uint64_t instead of double. While
>> double works, perhaps I should change the double here to uint64_t for
>> consistency?
>
> I'm wonde
On Fri, Nov 10, 2017 at 10:36:17AM -0800, Elijah Newren wrote:
> Thanks for taking a look!
>
> On Fri, Nov 10, 2017 at 10:26 AM, Stefan Beller wrote:
> > From a technical perspective, I would think that if
> > (num_create <= rename_limit || num_src <= rename_limit)
> > holds true, that the double
Thanks for taking a look!
On Fri, Nov 10, 2017 at 10:26 AM, Stefan Beller wrote:
>> - if (rename_limit <= 0 || rename_limit > 32767)
>> - rename_limit = 32767;
>> if ((num_create <= rename_limit || num_src <= rename_limit) &&
>> - (num_create * num_src <= re
On Fri, Nov 10, 2017 at 9:39 AM, Elijah Newren wrote:
> In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14),
> the renameLimit was clamped to 32767. This appears to have been to simply
> avoid integer overflow in the following computation:
>
>num_create * num_src <= rena
In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14),
the renameLimit was clamped to 32767. This appears to have been to simply
avoid integer overflow in the following computation:
num_create * num_src <= rename_limit * rename_limit
although it also could be viewed as a h
6 matches
Mail list logo