[EGIT PATCH 2/4] Fix NB.decodeUInt16 to correctly handle the high byte
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Aug 18, 2008, 16:35 UTC
- Message-ID
- <1219077333-29226-2-git-send-email-spearce@spearce.org>
- In-Reply-To
- <1219077333-29226-1-git-send-email-spearce@spearce.org>
Our decodeUInt16 method was buggy and always cleared the high byte of the pair. This meant we always lost the upper 8 bits when we read in a 16 bit unsigned integer, possibly causing us to misread the data associated with that pair.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> --- org.spearce.jgit/src/org/spearce/jgit/util/NB.java | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/NB.java b/org.spearce.jgit/src/org/spearce/jgit/util/NB.java index c6176f8..fa13354 100644 --- a/org.spearce.jgit/src/org/spearce/jgit/util/NB.java +++ b/org.spearce.jgit/src/org/spearce/jgit/util/NB.java @@ -102,7 +102,7 @@ public static int compareUInt32(final int a, final int b) { * @return unsigned integer value that matches the 16 bits read. */ public static int decodeUInt16(final byte[] intbuf, final int offset) { - int r = (intbuf[offset] << 8) & 0xff; + int r = (intbuf[offset] & 0xff) << 8; return r | (intbuf[offset + 1] & 0xff); }
-- 1.6.0.87.g2858d