[
https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100184#comment-13100184
]
Sylvain Lebresne commented on CASSANDRA-2851:
---------------------------------------------
bq. Sounds like the problem is thinking of this as a generic hex conversion
function, rather than as "hex that specifically represents bytes."
Well, in a way those methods never pretended being generic hex to *bits*
conversion functions since they are called hex2bytes and bytes2hex. I still
think that the correct behavior for hex2bytes is to throw an exception on odd
sized input. And that CASSANDRA-1411 was a mistake: yes I understand that it's
annoying the first time you use '0' as token to get an exception and to have to
write '00', but if you had written '0', there is a good chance you had missed
the meaning of the input, i.e that it is an hex string representing a byte
array.
Now changing that behavior would not be backward compatible, so I wonder if we
really should do anything here. I would be in favor however to refactor the
code slightly so that hex2bytes do throw an exception on odd sized input (it
would be fine if the method was named hex2bits, but it's fishy with hex2bytes)
and to move the code that pads the input into ByteOrderedPartitioner, since
that is what it was meant to: simplify the input of tokens.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 1.0
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character
> inputs by prepending "0", which is OK - but it does this for any input with
> an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'?
> Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira