-count. With all types except C<"a">, C<"A">, C<"b">, C<"B">, C<"h">, C<"H">, and C<"P"> the
-pack function will gobble up that many values from the LIST. A C<*> for the
-repeat count means to use however many items are left. The C<"a"> and C<"A">
-types gobble just one value, but pack it as a string of length count,
-padding with nulls or spaces as necessary. (When unpacking, C<"A"> strips
-trailing spaces and nulls, but C<"a"> does not.) Likewise, the C<"b"> and C<"B">
-fields pack a string that many bits long. The C<"h"> and C<"H"> fields pack a
-string that many nybbles long. The C<"p"> type packs a pointer to a null-
-terminated string. You are responsible for ensuring the string is not a
-temporary value (which can potentially get deallocated before you get
-around to using the packed result). The C<"P"> packs a pointer to a structure
-of the size indicated by the length. A NULL pointer is created if the
-corresponding value for C<"p"> or C<"P"> is C<undef>.
-Real numbers (floats and doubles) are
-in the native machine format only; due to the multiplicity of floating
-formats around, and the lack of a standard "network" representation, no
-facility for interchange has been made. This means that packed floating
-point data written on one machine may not be readable on another - even if
-both use IEEE floating point arithmetic (as the endian-ness of the memory
-representation is not part of the IEEE spec). Note that Perl uses doubles
-internally for all numeric calculation, and converting from double into
-float and thence back to double again will lose precision (i.e.,
-C<unpack("f", pack("f", $foo)>) will not in general equal C<$foo>).
+count. With all types except C<"a">, C<"A">, C<"Z">, C<"b">, C<"B">, C<"h">,
+C<"H">, and C<"P"> the pack function will gobble up that many values from
+the LIST. A C<*> for the repeat count means to use however many items are
+left.
+
+=item *
+
+The C<"a">, C<"A">, and C<"Z"> types gobble just one value, but pack it as a
+string of length count, padding with nulls or spaces as necessary. When
+unpacking, C<"A"> strips trailing spaces and nulls, C<"Z"> strips everything
+after the first null, and C<"a"> returns data verbatim.
+
+=item *
+
+Likewise, the C<"b"> and C<"B"> fields pack a string that many bits long.
+
+=item *
+
+The C<"h"> and C<"H"> fields pack a string that many nybbles long.
+
+=item *
+
+The C<"p"> type packs a pointer to a null-terminated string. You are
+responsible for ensuring the string is not a temporary value (which can
+potentially get deallocated before you get around to using the packed result).
+The C<"P"> type packs a pointer to a structure of the size indicated by the
+length. A NULL pointer is created if the corresponding value for C<"p"> or
+C<"P"> is C<undef>.
+
+=item *
+
+The C<"#"> character allows packing and unpacking of strings where the
+packed structure contains a byte count followed by the string itself.
+You write I<length-item>C<#>I<string-item>.
+
+The I<length-item> can be any C<pack> template letter,
+and describes how the length value is packed.
+The ones likely to be of most use are integer-packing ones like
+C<"n"> (for Java strings), C<"w"> (for ASN.1 or SNMP)
+and C<"N"> (for Sun XDR).
+
+The I<string-item> must, at present, be C<"A*">, C<"a*"> or C<"Z*">.
+For C<unpack> the length of the string is obtained from the I<length-item>,
+but if you put in the '*' it will be ignored.
+
+ unpack 'C#a', "\04Gurusamy"; gives 'Guru'
+ unpack 'a3#A* A*', '007 Bond J '; gives (' Bond','J')
+ pack 'n#a* w#a*','hello,','world'; gives "\000\006hello,\005world"
+
+The I<length-item> is not returned explicitly from C<unpack>.
+
+Adding a count to the I<length-item> letter
+is unlikely to do anything useful,
+unless that letter is C<"A">, C<"a"> or C<"Z">.
+Packing with a I<length-item> of C<"a"> or C<"Z">
+may introduce C<"\000"> characters,
+which Perl does not regard as legal in numeric strings.
+
+=item *
+
+The integer types C<"s">, C<"S">, C<"l">, and C<"L"> may be
+immediately followed by a C<"!"> to signify native shorts or longs--as
+you can see from above for example a bare C<"l"> does mean exactly 32
+bits, the native C<long> (as seen by the local C compiler) may be
+larger. This is an issue mainly in 64-bit platforms. You can see
+whether using C<"!"> makes any difference by
+
+ print length(pack("s")), " ", length(pack("s!")), "\n";
+ print length(pack("l")), " ", length(pack("l!")), "\n";
+
+C<"i!"> and C<"I!"> also work but only because of completeness;
+they are identical to C<"i"> and C<"I">.
+
+The actual sizes (in bytes) of native shorts, ints, and longs on
+the platform where Perl was built are also available via L<Config>:
+
+The actual sizes (in bytes) of native shorts, ints, longs, and long
+longs on the platform where Perl was built are also available via
+L<Config>:
+
+ use Config;
+ print $Config{shortsize}, "\n";
+ print $Config{intsize}, "\n";
+ print $Config{longsize}, "\n";
+ print $Config{longlongsize}, "\n";
+
+=item *
+
+The integer formats C<"s">, C<"S">, C<"i">, C<"I">, C<"l">, and C<"L">
+are inherently non-portable between processors and operating systems
+because they obey the native byteorder and endianness. For example a
+4-byte integer 0x87654321 (2271560481 decimal) be ordered natively
+(arranged in and handled by the CPU registers) into bytes as
+
+ 0x12 0x34 0x56 0x78 # little-endian
+ 0x78 0x56 0x34 0x12 # big-endian
+
+Basically, the Intel, Alpha, and VAX CPUs and little-endian, while
+everybody else, for example Motorola m68k/88k, PPC, Sparc, HP PA,
+Power, and Cray are big-endian. MIPS can be either: Digital used it
+in little-endian mode; SGI uses it in big-endian mode.
+
+The names `big-endian' and `little-endian' are comic references to
+the classic "Gulliver's Travels" (via the paper "On Holy Wars and a
+Plea for Peace" by Danny Cohen, USC/ISI IEN 137, April 1, 1980) and
+the egg-eating habits of the Lilliputians.
+
+Some systems may even have weird byte orders such as
+
+ 0x56 0x78 0x12 0x34
+ 0x34 0x12 0x78 0x56
+
+You can see your system's preference with
+
+ print join(" ", map { sprintf "%#02x", $_ }
+ unpack("C*",pack("L",0x12345678))), "\n";
+
+The byteorder on the platform where Perl was built is also available
+via L<Config>:
+
+ use Config;
+ print $Config{byteorder}, "\n";
+
+Byteorders C<'1234'> and C<'12345678'> are little-endian, C<'4321'>
+and C<'87654321'> are big-endian.
+
+If you want portable packed integers use the formats C<"n">, C<"N">,
+C<"v">, and C<"V">, their byte endianness and size is known.
+
+=item *
+
+Real numbers (floats and doubles) are in the native machine format only;
+due to the multiplicity of floating formats around, and the lack of a
+standard "network" representation, no facility for interchange has been
+made. This means that packed floating point data written on one machine
+may not be readable on another - even if both use IEEE floating point
+arithmetic (as the endian-ness of the memory representation is not part
+of the IEEE spec).
+
+Note that Perl uses doubles internally for all numeric calculation, and
+converting from double into float and thence back to double again will
+lose precision (i.e., C<unpack("f", pack("f", $foo)>) will not in general
+equal $foo).
+
+=back