[
https://issues.apache.org/jira/browse/LANG-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb reopened LANG-747:
-----------------------
Assignee: Sebb
Thanks for the report.
If 0x80000000 is unsigned, it is the same as Integer.MIN_VALUE, whereas if it
is signed, it is invalid as a posititve int.
The NumberUtils code currently assumes that any 8 digit hex number is valid as
an Integer, i.e. the code assumes that hex numbers are unsigned.
The documentation does say that hex numbers may be negative, so the assumption
that hex numbers are unsigned is wrong, and 0x80000000-0xFFFFFFFF should be
treated as positive and therefore will require conversion to Long.
Likewise for a 16 digit hex number starting with 0x8-0xF; that will require a
BigInteger.
> NumberUtils does not handle Long Hex numbers
> --------------------------------------------
>
> Key: LANG-747
> URL: https://issues.apache.org/jira/browse/LANG-747
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
> Reporter: Sebb
> Assignee: Sebb
> Fix For: 3.2
>
>
> NumberUtils.createLong() does not handle hex numbers, but createInteger()
> handles hex and octal.
> This seems odd.
> NumberUtils.createNumber() assumes that hex numbers can only be Integer.
> Again, why not handle bigger Hex numbers?
> ==
> It is trivial to fix createLong() - just use Long.decode() instead of
> valueOf().
> It's not clear why this was not done originally - the decode() method was
> added to both Integer and Long in Java 1.2.
> Fixing createNumber() is also fairly easy - if the hex string has more than 8
> digits, use Long.
> Should we allow for leading zeros in an Integer?
> If not, the length check is trivial.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
