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

[Niels Thykier]

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