According to this calculator site (link text), when converting 3 from decimal to double, I should get 4008 0000 0000 0000
.
When using the 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 shall I do if I want to get the result 4008 0000 0000 0000
from Perl pack
output?
By the way, when using "float" - everything works like it is expected to be.
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
精彩评论