Re: pack, unpack and internal represenation of numbers

From the pack documentation:

The integer formats s, S, i, I, l, L, j, and J are inherently non-portable between processors and operating systems because they obey the native byteorder and endianness.

Which should be taken to imply that the other formats do not follow the endian-ness of the platform. So your orginal L solution was correct in this case, because dealing with the endian-ness is the whole point.

----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

Comment on Re: pack, unpack and internal represenation of numbers Download Code

Replies are listed 'Best First'.
Re^2: pack, unpack and internal represenation of numbers by 5mi11er (Deacon) on Jul 01, 2004 at 20:48 UTC
Ok, but shouldn't a number, at run time, "obey the native byte order and endianness" as well? If this integer were stored in integer form internally, and I unpack that into short ints, I should get some pattern of 0x01, 0x02, 0x03, and 0x04 depending on the endianness. Perl's internal representation is not integer, but it is also not "double float"; at least not as defined by pack/unpack. I think maybe what I'm really asking is: "How do I go about packing 0x01020304 such that I get "49545748" as my answer?" Realizing of course, this answer is valid only on similar architecture machines...	[reply]

Replies are listed 'Best First'.

Re^2: pack, unpack and internal represenation of numbers
by 5mi11er (Deacon) on Jul 01, 2004 at 20:48 UTC

If this integer were stored in integer form internally, and I unpack that into short ints, I should get some pattern of 0x01, 0x02, 0x03, and 0x04 depending on the endianness.

Perl's internal representation is not integer, but it is also not "double float"; at least not as defined by pack/unpack.

I think maybe what I'm really asking is: "How do I go about packing 0x01020304 such that I get "49545748" as my answer?" Realizing of course, this answer is valid only on similar architecture machines...

[reply]