«

"Lawrence" <> wrote in message
news: ups.com...
> On Feb 17, 5:27 pm, "Lawrence" <xmarl...@gmail.com> wrote:
>> To answer your question let me explain.
>> I transfer the file using my own java program, I use simple chunks of
>
> Sorry for the bad quoting before.
> I just tried with a hex editor to open a file send on both sides,
> and they are equal.
> So the problem is in the function.
> For a file that has inside the 4 characters "CIAO" hex [ 43 49 41
> 4F ]
> on MAC the hash is [B@425743
> For the same file, on a Windows machine is [B@472d48
>
> Done again on a mac is [B@238016.
> Done again on the windows machine is [B@3ae941
>
> I don't understand .. how is this possible ?

"[B@425763" means "This is a byte array, and it's object number 425763 in
the JVM". It doesn't say anything about the contents of the byte array. I
presume it comes from code like

byte[] barr.
System.out.println(barr.toString());

Try something like

for (int i = 0; i < barr.length; i++)
{
System.out.print(Integer.toHexStrng(barr[i] & 0xFF);
System.out.print(", ");
}

to see what the byte array contains..

Lothar Kimmeringer wrote:
>> sb.append(Integer.toHexString(digest[i] & 0xff);

Lawrence wrote:
> I need to have a look back to shift operator and bit wise and)

This use of the operator & is called "masking", and the int operand 0xff in
this example a "mask".

Only the bits in the other operand that match position with the 1s in the mask
will make it through to the result. The rest are masked out, as with a resist
in a circuit-board etching.

In the given example, the lowest byte of digest[i] will show up in the lowest
byte of the argument to toHexString(), masked in by the 0xff; the upper bytes
of the argument will all be zeroed. This has an effect of ensuring a positive
argument to toHexString().

- Lew

[SNIP]
>the upper bytes
> of the argument will all be zeroed. This has an effect of ensuring a positive
> argument to toHexString().
[SNIP]
> - Lew


Wait.
I though something different.
Hex rappresent at most 16 different combinations per digit, so two hex
digit rappresent 256 combination
, 8 bits, 1 byte.
Then it does some kind of implicit conversion applying and bit wise
operation between
0xFF which is like a bit string of 8 1s.
The result should be an number (what, hex or int or even a byte)
that if is smaller than 16 means it will be of only one digit,
therefore
a 0 is added in front of the hex digit.

Am I wrong ?

Lawrence wrote:

> Hex rappresent at most 16 different combinations per digit, so two hex
> digit rappresent 256 combination

Hex represents a value with the base of 16. One "digit" can
therefore represent numbers from 0 to 15. How many "combinations"
can be represented depends on the bitlength. Integer (used here)
can hold 32 Bits, so a Hex-number can be up to 8 Hex-digits
(aka Nibbles) long.

> , 8 bits, 1 byte.
> Then it does some kind of implicit conversion applying and bit wise
> operation between
> 0xFF which is like a bit string of 8 1s.

The usage of the mask has the reason to covert the signed byte
to an unsigned int-value. Alternatively you can do a
digest[i] + (digest[i] < 0 ? 256 : 0);
But this is much more complicated to read and understand what
is intended to happen here.

If you don't do this kind of thing and you just do a
Integer.toHexString((int) digest[i]);
a set value of e.g. 255 will lead to the hex-value
of FFFFFFFF to be returned. Why? If you set 255 (0xff)
to a byte that is signed, the value will be -1 after
that (that's what 0xff represents). If you just cast
it to an int, the value still is -1, there are just
more bits being set (0xffffffff).

The construct (digest[i] & 0xff) tells the VM, to
cast digest[i] to int (0xffffffff) and do a logical
AND with the value 0xff). The result is 0x000000ff,
which is the same value as being set previously.

> The result should be an number (what, hex or int or even a byte)
> that if is smaller than 16 means it will be of only one digit,
> therefore
> a 0 is added in front of the hex digit.

That's the first check. Alternatively the if-statement
can be if(digest[i] >= 0 && digest[i] < 16) but again
this is harder to read and understand two weeks later.

In C you just would use "unsigned byte" (I know byte
doesn't exist in C but I don't want to start confusing
things staring to use char here). In Java you always
have to do these kind of things when handling unsigned
data with signed types.


Regards, Lothar
--
Lothar Kimmeringer E-Mail:
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

Lawrence wrote:
>> Hex rappresent at most 16 different combinations per digit, so two hex
>> digit rappresent 256 combination

Don't confuse a numeric value with the String representation of that value.

>> Then it does some kind of implicit conversion applying and bit wise
>> operation between
>> 0xFF which is like a bit string of 8 1s.

0xff is a number, equal to 255. It is 32 bits long, not 8. The top 24 bits are 0.

>> The result should be an number (what, hex or int or even a byte)

In this case, an int. 0xff is an int, digest[i] is no wider than an int, so
the result of & is an int.

>> that if is smaller than 16 means it will be of only one digit,
>> therefore

Digits only apply to the String form. The int form is always four bytes long.

>> a 0 is added in front of the hex digit.

In the String representation only.

You need to study types and numeric operations in Java.

- Lew

[SNIP}
> You need to study types and numeric operations in Java.
>
> - Lew

I do.
Thank you a lot, all of you.
At least now I understand how it does it, I hate when I don't.

Lawrence

Lew wrote:
>> You need to study types and numeric operations in Java.

Lawrence wrote:
> I do.
> Thank you a lot, all of you.
> At least now I understand how it does it, I hate when I don't.

I apologize. I should have phrased that advice, "The reasons for this behavior
are in the definitions of (numeric) types and numeric operations in Java."

In a nutshell, binary numeric operations perform unary and binary operand
promotion at various points. Literals like '0xff' have the virtue of
representing positive int values while looking an awful lot like unsigned byte
values. This makes them ideal to mask (signed) narrow values into positive
wider ones.

Some view Java's snubbing of unsigned bytes as a flaw. That's as may be, but
it is a reality for good or ill.

In the world of implicit conversions, be very, very aware.

Gird your loins and venture into the world of unadorned truth in the Java
Language Specification (JLS).

<http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html>

Integer literals:
<http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.1>

The integer bitwise operators:
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#5233>

Numeric promotions:
<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.6>

- Lew