Perl stores its ints at type j/J rather than binary.
No, not really. Perl can store an integer value as an IV (signed integer of some size determined when Perl was built), a UV (unsigned), an NV (a double or similar), or a PV (a string). But that is at a lower layer that you normally don't have to worry about.
Perl deals with scalars. A scalar can be a string or a number (and a few other types of values). Numeric values are automatically converted to string values when needed. String values are also automatically converted to numeric values but conversion in that direction can have issues, of course, as not all strings represent a numeric value.
Perl's printf is not C's printf, though they certainly have a lot in common. For a numeric format specifier, Perl's printf() interprets the scalar as a numeric value. If the scalar already has a numeric value, than that is easy. If the scalar only has a string value, then Perl tries to interpret the string as a number, which means only interpreting it as a base-ten string (integer or floating-point).
As noted in the first sentence of pack, the value returned is a string. That is appropriate as a Perl string can hold an arbitrary list of bytes.
If you get a string with $str = pack "S", 0x3232;, then $str will be a string of two bytes where each byte has the value of 0x32. On an ASCII platform, that string is simply "22". If you then do printf "%x\n", $str, then Perl will output "16\n" because 0x16 == 22. You gave printf a scalar containing a string at the position where it needed a number (because '%x' expects a number) so it interpreted the string as a base-ten number and got the numeric value 22 from the string "22".
And yet the number that you stored in that string was the number 0x3232.
Maybe I can spend a few more hour and figure out how to UNPACK a binary blob into a string of 1s and 0s.
That is easy: $base2 = unpack "B*", $blob;
|