«

HELLO.....I M NOT ABLE TO GET WHAT IS THE PROBLEM WITH MY
PROGRAM....PLZ LET ME KNOW THAT
class LtoSa
{

public static void main(String args[])
{
long l = Long.parseLong(args[0]);
short[] buf1 = new short[4];
//for(short s1 = (short)9999;s1<=9999;s1++)
//{

buf1[0]=(short)((l & 0xffff000000000000l)>>4;
buf1[1]=(short)((l & 0x0000ffff00000000l)>>32);
buf1[2]=(short)((l & 0x00000000ffff0000l)>>16);
buf1[3]=(short) (l & 0x000000000000ffffl);
//buf[1] = 0;

//System.out.print(s1+":\t");
for(int j = 0; j<4;j++)
{
System.out.print(buf1[j]+"\t");
}

System.out.println();
//}

l |= buf1[0] & 0xFFFF;
l <<= 16;
l |= buf1[1] & 0xFFFF;
l <<= 16;
l |= buf1[2] & 0xFFFF;
l <<= 16;
l |= buf1[3] & 0xFFFF;

System.out.println("Long value:"+l);


}
}

Dinesh wrote:

> l = 0;
or
> l = buf1[0] & 0xFFFF;
> l <<= 16;
> l |= buf1[1] & 0xFFFF;
> l <<= 16;
> l |= buf1[2] & 0xFFFF;
> l <<= 16;
> l |= buf1[3] & 0xFFFF;

Dinesh wrote:
> HELLO.....I M NOT ABLE TO GET WHAT IS THE PROBLEM WITH MY
> PROGRAM....PLZ LET ME KNOW THAT

"Plz" don't shout.

> class LtoSa

Why not public?

> {
>
> public static void main(String args[])
> {
> long l = Long.parseLong(args[0]);

'l' (the letter 'ell') is a terrible choice for a variable name, since in many
fonts it looks just like the numeral '1' (one).

> short[] buf1 = new short[4];
> //for(short s1 = (short)9999;s1<=9999;s1++)

If uncommented, this would be a loop of one pass. For SSCCEs on Usenet it is
best to trim this type of comment. Otherwise, what point are you making by
leaving the comment in?

> //{
>
> buf1[0]=(short)((l & 0xffff000000000000l)>>4;

The final 'ell' of the long constant should be upper case so that it doesn't
look like a 'one'.

> buf1[1]=(short)((l & 0x0000ffff00000000l)>>32);
> buf1[2]=(short)((l & 0x00000000ffff0000l)>>16);
> buf1[3]=(short) (l & 0x000000000000ffffl);
> //buf[1] = 0;
>
> //System.out.print(s1+":\t");
> for(int j = 0; j<4;j++)
> {
> System.out.print(buf1[j]+"\t");
> }
>
> System.out.println();
> //}
>
> l |= buf1[0] & 0xFFFF;

buf1 [0] is already a short, so ANDing it with 0xFFFF doesn't really do anything.

'ell' was not cleared before the |=, so the |= of buf1 [0] combines the high
short of the original value with the low short of the original value.

Since the left side of the assignment is a long, the right side will be
widened to long, which for negative values of the short value has the side
effect of setting the high 48 bits of 'ell' to all ones.

> l <<= 16;
> l |= buf1[1] & 0xFFFF;

Here, if buf1 [1] is negative, the high 48 bits of 'ell' will all be set to
ones, thus wiping the information from the ORing of buf1 [0]. This would also
leave the high 16 bits set after the next two steps regardless of the values
of buf1 [2] or buf1 [3].

> l <<= 16;
> l |= buf1[2] & 0xFFFF;

Likewise, a negative buf1 [2] will set the high 48 bits, guaranteeing that the
high 32 will remain set in the end.

> l <<= 16;
> l |= buf1[3] & 0xFFFF;

Likewise, a negative buf1 [3] will set the high 48 bits.

>
> System.out.println("Long value:"+l);

A very restricted set of initial values for 'ell' will match the resulting value.

> }
> }

I was able to compile and run the program pretty much as you presented it,
save that I declared the class public, and put it in a package 'testit.

$ java -cp . testit.LtoSa 14135935696
0 3 19089 17104
Long value:4814348015794995920

There is no "problem with [the] program" if you intended the behavior it
evinces. You did not tell us the intent of the program.

- Lew

Lew wrote:
> Dinesh wrote:
....
>> l <<= 16;
>> l |= buf1[1] & 0xFFFF;
>
> Here, if buf1 [1] is negative, the high 48 bits of 'ell' will all be set to
> ones, thus wiping the information from the ORing of buf1 [0]. This
> would also leave the high 16 bits set after the next two steps
> regardless of the values of buf1 [2] or buf1 [3].
....

This comment seems to ignore the effect of "& 0xffff". Because of it,
only the least significant 16 bits of the right hand side of the |= can
ever be non-zero, regardless of the value of buf1[1].

This program:

public class TestLongBits {
public static void main(String[] args) {
long i = 0x42;
short buff = -3;
i <<= 16;
i |= buff & 0xffff;
System.out.println(Long.toHexString(i));
}
}

prints:

42fffd

Patricia

Lew wrote:
> Dinesh wrote:
....
>> l |= buf1[0] & 0xFFFF;
>
> buf1 [0] is already a short, so ANDing it with 0xFFFF doesn't really do
> anything.

Ah, I didn't notice this comment, which explains the confusion about the
"& 0xffff" later.

The short gets converted to int, due to binary numeric promotion, before
evaluation of the "&". Suppose the short is -3, 0xFFFD. The conversion
produces 0xFFFFFFFD. The & result is 0x0000FFFD. It is then promoted to
long getting 0x000000000000FFFD.

Patricia

Patricia Shanahan wrote:
> Lew wrote:
>> Dinesh wrote:
> ...
>>> l |= buf1[0] & 0xFFFF;
>>
>> buf1 [0] is already a short, so ANDing it with 0xFFFF doesn't really
>> do anything.
>
> Ah, I didn't notice this comment, which explains the confusion about the
> "& 0xffff" later.
>
> The short gets converted to int, due to binary numeric promotion, before
> evaluation of the "&". Suppose the short is -3, 0xFFFD. The conversion
> produces 0xFFFFFFFD. The & result is 0x0000FFFD. It is then promoted to
> long getting 0x000000000000FFFD.
>
> Patricia

Duhy!!

I am never too old to learn. Thanks, Patricia.

- Lew