Thanks. I think so. So the issue is that unpack takes a string as an argument (which I now see on the description in perlfunc), so it's unpack itself that forces the number to be interpreted as a string? Packing it explicitly as an integer gives it an integer to unpack -- though pack, according to perlfunc, also produces a string. I guess I just lack a basic understanding about how Perl stores data. My understanding of data types is essentially C-centric (char or int or short or string).

You're almost there.

As you say, unpack takes a string as its argument. If you supply an integer, then Perl quietly converts it to a (human readable) string for you, just as it does when do print 0; It 'ascii-ises' the number. In C terms, Perl does an itoa() on it.

Conversely, when you pack the number, the string returned contains the machine readable, binary representation embedded within a string. In C terms, it is like doing:

int i = 0;

printf( "%s", (char*)&i );
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Thanks a lot; I think I've got it.