reading c-generated binary

[hugodogo]

I need to read in Java some binary files created by c-programs. The
c-code runs on Linux or Solaris. When I run a test case I get the
following bytes patterns for the integer 1 (generated by cat output |
od -x).

C-code, Linux : 0001 0000
C-Code, Sparc : 0000 0001
Java : 0000 0100

This suprises me. The C-code on Sparc is big-endian, but the c-code on
Linux isn't little-endian and the Java output isn't big-endian. How do
I make sense of these patterns?

Thanks

 

[Daniel Cer]

I need to read in Java some binary files created by c-programs. The

c-code runs on Linux or Solaris. When I run a test case I get the
following bytes patterns for the integer 1 (generated by cat output |
od -x).

C-code, Linux : 0001 0000
C-Code, Sparc : 0000 0001
Java : 0000 0100

This surprises me. The C-code on Sparc is big-endian, but the c-code on
Linux isn't little-endian and the Java output isn't big-endian. How do
I make sense of these patterns?

I think the confusion is probably being caused by od processing the 32-bit
integers as a pair of shorts/16-bit words. When it does this and you're
running on a little endian machine, the results it prints out can look
a little bit managed.

More specifically, notice that for the results you gave above, the
location of the '1' is in the 16 bit word you would expect it to be
in for both the Java & x86/Linux results. However, within the 16 bit word,
the bit appears to be in the wrong byte. This kind of behavior could be
explained by "od -x" being run on a little endian machine.

In any case, to get more sensible results, just run "od -t x1" rather
than just "od -x", thus telling it to use an 8-bit word size.

-Dan

 

[Roedy Green]

I need to read in Java some binary files created by c-programs. The
c-code runs on Linux or Solaris. When I run a test case I get the
following bytes patterns for the integer 1 (generated by cat output |
od -x).

C-code, Linux : 0001 0000
C-Code, Sparc : 0000 0001
Java : 0000 0100

If you need to do this on older Javas, see
http://mindprod.com/products1.html#LEDATASTREAM

In JDK 1,4+ you have NIO which can deal with little endian data.


LeDataStream works identically to DataInputStream and DataOutputStream
so it has a lower learning curve, but it is one more package to bundle
in your jar.

 

[hugodogo]

Thanks all, both suggestions were very helpful.