views:

35

answers:

1

Hi,

According to this calculator site (link text) , when converting 3 from dec to double I get 4008 0000 0000 0000

When using Perl pack function, with the parameter "d>*" , I expected to see 4008 0000 0000 0000 as I use this function:

print $File pack("d>*",3);

But when I "Hexdump" to the Perl output file, I see 0840 0000 0000 0000

I thought that it might belong to the big/little endian, but when trying the little endian:

print $File pack("d<*",3);

I get this: 0000 0000 0000 4008

What shell I do if I want to get this result 4008 0000 0000 0000 from Perl pack output ?

Thanks.

By the way, when using "Float" - every thing works like it expected to be.

+4  A: 

Your intuition about the byte order in Perl is correct, but I think that the hexdump output doesn't mean what you think it does. It looks like hexdump is displaying each pair of bytes in a consistent but counterintuitive order. Here are some experiments you can run to get your bearings.

# bytes are stored in the order that they are printed
$ perl -e 'print "\x{01}\x{02}\x{03}\x{04}"' | od -c
0000000 001 002 003 004
0000004

# perl reads the bytes in the correct order    
$ perl -e 'print "\x{01}\x{02}\x{03}\x{04}"' | perl -ne 'print map{ord,$"}split//'
1 2 3 4

# but the way  hexdump  displays the bytes is confusing (od -h gives same output)
$ perl -e 'print "\x{01}\x{02}\x{03}\x{04}"' | hexdump
0000000 0201 0403
0000004
mobrule
Piping into `hex` results in `01 02 03 04`. This is the version from [esr](http://catb.org/esr/software.html), and also in general superior to `hexdump` from util-linux or `xxd`.
daxim
OK, Perl is doing fine. The solution is to add "-C" to Hexdump:"hexdump -C [FileName]" will show the expected results.
YoDar