You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Matt Ryan (JIRA)" <ji...@apache.org> on 2017/05/04 15:21:04 UTC

[jira] [Comment Edited] (OAK-6164) IOUtils.nextPowerOf2() returns lower power of 2 for very high int values

    [ https://issues.apache.org/jira/browse/OAK-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15996899#comment-15996899 ] 

Matt Ryan edited comment on OAK-6164 at 5/4/17 3:20 PM:
--------------------------------------------------------

[~mduerig] I wondered about doing that also.  The problem is that there will always be a range of values for which we can't compute the next highest power of two, for any integer type.  However, it may work to accept an {{int}} as the input but return a {{long}} as the output.

For any value in the range [0x40000001, 0x7FFFFFFF], the next highest power of 2 would be 0x80000000.  Interpreted as an {{int}} value this is actually {{Integer.MIN_VALUE}} because of the sign bit, but this of course works as a {{long}}.  So this can work for all valid positive {{int}} input values.  But if the caller were to cast the result back to an {{int}} they would then end up with a negative number (--2147483648) even though the {{long}} value is a positive value (2147483648).

So that's a minor problem, but I think your point is that this would be better than not accepting all valid positive {{int}} values and throwing an exception when the range is exceeded.  I tend to agree.

However, this does have the effect of changing the function signature (return value from {{int}} to {{long}}).  I don't think the function is actually used anywhere else in Oak so I'm not sure making that change matters too much, but it does technically constitute an API change.

I'll make another patch anyway, and then we can decide which we like best.


was (Author: mattvryan):
[~mduerig] I wondered about doing that also.  The problem is that there will always be a range of values for which we can't compute the next highest power of two, for any integer type.  However, it may work to accept an {{int}} as the input but return a {{long}} as the output.

For any value in the range [0x40000001, 0x7FFFFFFF], the next highest power of 2 would be 0x80000000.  Interpreted as an {{int}} value this is actually {{Integer.MIN_VALUE}} because of the sign bit, but this of course works as a {{long}}.  So this can work for all valid positive {{int}} input values.  But if the caller were to cast the result back to an {{int}} they would then end up with a negative number (--2147483648) even though the {{long}} value is a positive value (2147483648).

So that's a minor problem, but I think your point is that this would be better than not accepting all valid positive {{int}} values and throwing an exception when the range is exceeded.  I tend to agree.

I'll make another patch.

> IOUtils.nextPowerOf2() returns lower power of 2 for very high int values
> ------------------------------------------------------------------------
>
>                 Key: OAK-6164
>                 URL: https://issues.apache.org/jira/browse/OAK-6164
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: commons
>            Reporter: Matt Ryan
>            Assignee: Michael Dürig
>            Priority: Minor
>             Fix For: 1.7.0, 1.8
>
>         Attachments: OAK-6164.patch.1, OAK-6164.patch.2
>
>
> In the IOUtils.nextPowerOf2() method, all int values are accepted as input.  However, there are valid signed integer values that this method accepts as input, but for which a lower power of 2 value is returned.
> This occurs for values that are valid signed integer values that are greater than the highest possible power of two value in the signed integer range.  Signed integer values have the maximum value of 0x7FFFFFFF, but the maximum possible power of two in the signed integer range is 0x40000000.  (The current implementation incorrectly identifies the maximum possible power of two as 0x3FFFFFFF, due to how it is computed by doing integer division of 0x7FFFFFFF / 2.)
> In the current implementation any input in the range of [0x40000000, 0x7FFFFFFF] is a valid signed integer input, but the method will return 0x3FFFFFFF as the next valid max power of 2.
> Two minor things need to be fixed:
> * If the input is 0x40000000, the return value needs to be 0x40000000, instead of 0x3FFFFFFF which is not a valid power of 2.
> * If the input is in the range [0x40000001, 0x7FFFFFFF] I propose the method should instead throw an IllegalArgumentException and indicate that it is not possible to compute a next power of 2 for a number in that range.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)