Bug#661632: javahelper: jh_depends determines incorrect class version on sparc
niels at thykier.net
Mon Mar 12 20:31:39 UTC 2012
On 2012-03-12 19:11, Kai Ruschenburg wrote:
> 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'`
>>> 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
>> 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. :)
> Best regards
More information about the pkg-java-maintainers