[ 
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

        

Reply via email to