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. 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. > Can you give me a hexdump of the 16 characters of the class file? This is not a problem of the class file. You can reproduce it with any class file. Here are the first 16 bytes of the file I used as an example in my report (compiled for Java 1.4): $ hd -n 16 Test.class 00000000 ca fe ba be 00 00 00 30 00 0f 0a 00 03 00 0c 07 |.......0........| 00000010 This is on sparc: $ hd -s 7 -n 1 -d Test.class 00000007 30 |0| 0000007 12288 0000008 This is on i386 (same class file): $ hd -s 7 -n 1 -d Test.class 00000007 30 |0| 0000007 00048 0000008 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. > [...] > > ~Niels Best regards Kai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
