Re: [PATCH 2/4] Remove silent clamp of renameLimit

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)

Re: [PATCH 2/4] Remove silent clamp of renameLimit

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

Re: [PATCH 2/4] Remove silent clamp of renameLimit

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

Re: [PATCH 2/4] Remove silent clamp of renameLimit

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) && >> -

Re: [PATCH 2/4] Remove silent clamp of renameLimit

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: > >

[PATCH 2/4] Remove silent clamp of renameLimit

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