I have a C executable which writes a bunch of unsigned integers, unsigned shorts and floats to a data file. The C program is compiled using MinGW, and the data file is written to using calls to fwrite. This data file is later opened and the values read by a Java program. The problem is, when reading the file in using the Java program, the byte order for the primitives (int, short and float) seems to be reversed. No problem, I thought; I'll just read the primitives in byte-by-byte and swap the order. This worked- I now have a function like this:

    private int readInt(DataInputStream in) {
        int value = 0;
        
        try {
           value = (in.readUnsignedByte()) | (in.readUnsignedByte()<<8) |
                   (in.readUnsignedByte()<<16) | (in.readUnsignedByte()<<24);
        } catch(Exception _e) {}
        
        return value;
    }

And a similar readShort function. The problem occurs when it comes to floats- read in using the standard DataInputStream function readFloat() they are all messed up, just like the ints/floats. From this, I guess that they are mangled in the same way, with the byteorder reversed- unfortunately, as far as I'm aware, bitwise operations can't be performed on floats, so I can't write a function like the above to re-arrange their component bytes. So: - Can anyone recommend me a way to read these floats correctly? - Can anyone tell me why this order-reversal happens? For the first problem, I quickly came up with the solution of reading 4 bytes off the input stream, writing them to an output stream in the reverse order and then reading them back in as a float. This seems so far fetched a solution, though, that I'm worried I've overlooked something simple. Rates to anyone who can help!

Thanks, rate++ :o)

One more thing. I'm doing this in order to read in a 3d model from a data file, and currently using one created by using the C program to convert a 3ds file to a more readable format. I hope to implement real 3ds support at some point- should I expect 3ds files to be written in the same way (using little endian)? And would it be the same for other formats? My guess is yes- but I'd rather just be clear on that.

Edit: Just checked the 3ds specification (googled for "3ds file endian"- should have done that before posting, really) and it seems it is indeed little-endian. So it seems this is the way it's usually done (can someone confirm/deny that?)

Thanks again.