Pack and unpack allow Perl to deal with primitive data types that are often found in binary file formats or in network packets. Where space is at a premium, data is often encoded using short, space-efficient binary representations rather than text.

What many of the pack formats involve is different representations of numbers. Your "signed char" is an example of these. Some of these types are specific sizes (which translates to fixed numeric ranges). Where it says in the "perldoc -f pack" document that something is exactly so many bits, these are fixed sizes:<bl>

unsigned 8 bits (unsigned char, 'C'): 0 - 255

signed 8 bits (signed char, 'c'): -128 - 127

unsigned 16 bits (unsigned short, 'S', 'N', 'V'): 0 - 65535

signed 16 bits (short, 's', 'n', 'v'): -32678 - 32767

unsigned 32 bits (unsigned long, 'L', 'V'): 0 - 4294967295

signed 32 bits (long, 'l', 'v'): -2147483648 - 2147483647

</bl> What complicates the representation of numbers as streams of bits is that the bits are arranged into bytes. So if you have a 32 bit number that takes 4 bytes to represent, there are several different ways to arrange those 4 bytes. Hence the various different "byte orders".

Other pack formats deal with other kinds of encodings for numbers, or representations of strings. These, again, are typically found in files or in network packets.

Unless you're dealing with external files or network protocols that use binary or other non-text representation of data, you shouldn't need to bother with pack

But it's quite useful when you need it, like any power tool. For instance, I couldn't have written Archive::Zip nearly as fast without it, because the zip file format has fixed binary headers.