Bug#661632: javahelper: jh_depends determines incorrect class version on sparc

[Kai Ruschenburg]

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