On 2012-03-12 19:11, Kai Ruschenburg wrote: > Hi, > > On Mon, 12 Mar 2012 09:26:06 +0100, Niels Thykier wrote: >> On 2012-02-28 19:08, Kai Ruschenburg wrote: >> [...] >>> Changing line 37 from >>> new=`hd -s 7 -n 1 -d "$i" | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'` >>> to >>> new=`hexdump -s 6 -n 2 -e '/1 "%u "' -e '/2 " r 256 * + p"' "$i" | dc` >>> should fix this. >>> >> >> To be honest, I do not see why the "old" code should fail. The >> specification says that bytes "6 and 7" are read as an unsigned short in >> big-endian. >> Sure, our code fails if the class version suddenly jumps above 255 >> (because we only read the last byte). However, we are at 51 with Java7 >> so I do not see that coming anytime soon. > > Right, as long as the class version fits into one byte, reading byte 7 is > sufficient. But this is not the problem. The problem is hexdump's -d > option, which (according to "man hd") produces a zero-filled *two-byte* > decimal display. >
Right, I thought it only produced a single byte output. Assuming I got my hd-foo right, I believe: $ hd -n 1 -s 7 -e '/1 "%02d"' <classfile> would also produce the right result. If you can confirm this, I would like to use that instead (saves dependency for dc and it even simplier than the current code). > So even if you do not read byte 6 (which for now is zero anyway), the > output of "hd -s 7 -n 1 -d" is byte 7 filled with zeros to make it > two-byte wide. This two-byte representation is differing on sparc > compared to i386. > Good old endian issues, I presume. >> [...] > > As you can see, on sparc the decimal representation of 0x3000 is printed, > whereas on i386 it is the decimal representation of 0x0030. > > Please excuse that this was not clear in my initial report. > That is quite all right. I had long forgotten hd did not output a single byte. :) >> [...] >> >> ~Niels > > Best regards > > Kai ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
