I was looking at an implementation of file-based mergesort from GitHub, and found the following snippet.
1234567891011121314151617181920212223242526
/** * Author: cowtowncoder * https://github.com/cowtowncoder/java-merge-sort/blob/master/src/main/java/com/fasterxml/sort/std/ByteArrayComparator.java * * Simple implementation of comparator for byte arrays which * will compare using <code>unsigned</code> byte values (meaning * that 0xFF is creator than 0x00, for example). */publicclassByteArrayComparatorimplementsComparator<byte[]>{@Overridepublicintcompare(byte[]o1,byte[]o2){finalintlen=Math.min(o1.length,o2.length);for(inti=0;i<len;++i){// alas, sign extension means we must do masking...intdiff=(o1[i]&0xFF)-(o2[i]&0xFF);if(diff!=0){returndiff;}}returno1.length-o2.length;}}
What is the meaning of the remark “// alas, sign extension means we must do
masking...”? What’s the deal with the masking?
ol[i] is a byte, i.e. 8 bits. But if you try to subtract two bytes
123
bytea=0x00;byteb=0xff;bytec=a-b;
This will produce a compiler error, because Java’s - (minus) operator
promotesbytes to ints before performing the -, thus - produces an
int, and you can’t assign an int to a byte (without a cast, because you’d lose bits).
So what about
123
bytea=0x00;byteb=0xff;intc=a-b;
The problem is that (according to the spec in the doc comment), we want c to
be negative. However note: