Question

I am sending data between Java and iPhone/objC clients. The Java client has an established middleware component that I am using to test integration of the new client to the middleware.

I have a problem with all byte shift operations. The Java code is in production and can not be modified. Since the double seems to be the most extensive I will post it.

To send from objC:

-(void)putDouble:(NSNumber *)v{

    unsigned long long n = [v unsignedLongLongValue];

    dataToSend = [NSMutableData data];

    long long i = (int)n & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(n)]];


    i = ((int)n >> 8) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(n)]];


    i = ((int)n >> 16) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(n)]];


    i = ((int)n >> 24) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(n)]];


    i = ((int)n >> 32) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(i)]];


    i = ((int)n >> 40) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(i)]];


    i = ((int)n >> 48) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(i)]];


    i = ((int)n >> 56) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(i)]];
    [self send:dataToSend];

}

Java receives:

/*
 * Retrieve a double (64-bit) number from the stream.
 */
private double getDouble() throws IOException
{
    byte[] buffer = getBytes(8);

    long bits =
            ((long)buffer[0] & 0x0ff) |
            (((long)buffer[1] & 0x0ff) << 8) |
            (((long)buffer[2] & 0x0ff) << 16) |
            (((long)buffer[3] & 0x0ff) << 24) |
            (((long)buffer[4] & 0x0ff) << 32) |
            (((long)buffer[5] & 0x0ff) << 40) |
            (((long)buffer[6] & 0x0ff) << 48) |
            (((long)buffer[7] & 0x0ff) << 56);

    return Double.longBitsToDouble(bits);
}

When I send [[WVDouble alloc]initWithDouble:-13456.134] from objC

java gets double 5.53E-322

The problem is on the objC side, since the java is in production with other development environments. With all production clients -13456.134 is the converted result.

Here is the sendDouble code the java client uses: `

 // Write a double (64-bit) number to the stream.

private void putDouble(double number) throws IOException
{
    long n = Double.doubleToLongBits(number);

    // have to write these in reverse order to be comptible

    stream.write((int)(n) & 0x0ff);
    stream.write((int)((n >>> 8)) & 0x0ff);
    stream.write((int)((n >>> 16)) & 0x0ff);
    stream.write((int)((n >>> 24)) & 0x0ff);
    stream.write((int)((n >>> 32)) & 0x0ff);
    stream.write((int)((n >>> 40)) & 0x0ff);
    stream.write((int)((n >>> 48)) & 0x0ff);
    stream.write((int)((n >>> 56)) & 0x0ff);
}

//--------------------------------------------------------------------------------

`

Answer 1

As @Vovanium pointed out, you’re getting the long long value of the double, which for your example will return -13456. No fraction, no exponent.

In your shift and mask operations you’re casting to an int too early. You need to apply the cast after the shift and mask. Also, wrapping it up in a loop reduces the mount of code to change.

int i;
int j;

for (j = 0; j < sizeof(n); j++) {
    i = (int)(n >> (j*8)) & 0x0ff;
    [dataToSend appendData:[NSMutableData dataWithBytes:&i length:sizeof(i)]];
}
[self send:dataToSend];

Do note that, according to the JavaDocs for Double, Java expects the bits will have a particular order. You will get incorrect values if casting from double to unsigned long long does not produce that bit order. In that case it may be necessary to rearrange the bits before sending.

Bit 63 (the bit that is selected by the mask 0x8000000000000000L) represents the sign of the floating-point number. Bits 62-52 (the bits that are selected by the mask 0x7ff0000000000000L) represent the exponent. Bits 51-0 (the bits that are selected by the mask 0x000fffffffffffffL) represent the significand (sometimes called the mantissa) of the floating-point number.

update:

Make sure you pick up @Vovanium’s change so you’re working on the right set of bits:

double nd = [v doubleValue];
unsigned long long n = *(long long *)&nd;

Try testing with a value of -1.0. The IEEE 754 bit pattern for a -1.0 is:

0xbff0000000000000

And, when serialized, the bytes would be

00 00 00 00 00 00 f0 bf

If instead you get these bytes:

bf f0 00 00 00 00 00 00

you are encountering an endian order problem. If that’s the case, then you
would change the line in my example code to

    i = (int)(n >> ((sizeof(n) - j - 1)*8)) & 0x0ff;

That just reverses the order in which the long long is decoded.