RFR: 8234331: Add robust and optimized utility for rounding up to next power of two+

[Claes Redestad]

I'm working on a new version, but I'm also out sick, so don't expect
anything soon.

I just want to point out that the "round up to power of 2"
implementations I've seen seem prone to the same kind of overflows as a
next up would, just not for exactly the same set of inputs.

/Claes

On 2019-11-28 21:23, John Rose wrote:
> On Nov 27, 2019, at 11:34 PM, Thomas Stüfe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>> In the end, I wonder whether we should have two kind of APIs, or a
>> parameter, distinguishing between "next power of 2" and "next power of 2
>> unless input value is already power of 2”.
> 
> Naming is important for clarity.  “Round up” means if it’s already “rounded”
> (whatever that means) the input is returned unchanged.
> 
> The other notion is a true “next up”, because it always increases —
> barring overflow.  The possibility of overflow makes the “next up” function
> more bug-prone than the “round up” function.
> 
> The usual trick for deriving that second function is to add one to the 
> argument
> to the first function, ensuring that the result will always increase.
> 
> If (for clarity) we implement a “next power of two” function, rather 
> than ask
> coders to use the +1 trick, the second function should be implemented in 
> terms of
> the first function using the +1 trick, maybe with an assert added 
> against overflow.
> 
> My $0.02.
> 
> — John
>