in reply to Re^4: Using pack to evaluate text strings as hexadecimal values
in thread Using pack to evaluate text strings as hexadecimal values

It doesn't give me a single format string that I can use to convert back and forth between "records" and "fields".

The "problem" is that you cannot have a single conversion that produces binary numeric data for internal math use, and also produces asciified hex string for display purposes.

It's the same as asking for a single printf format that will display an number as decimal and hex. It cannot be done.

The solution is to have two templates: 1 for internal packing and unpacking: 

$templ = 'A4 v d';;

@fields = ( 'fred', 12345, 123.456 );;

$record = pack $templ, @fields;;

print unpack $templ, $record;;
fred 12345 123.456

[download]

And another for unpack a record for display purposes:

$templ2 = 'A4 H4 H16';;

print unpack $templ2, $record;;
fred 3930 77be9f1a2fdd5e40

[download]

There is simply no way to implement a single template that would server both purposes.

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.

Replies are listed 'Best First'.
Re^6: Using pack to evaluate text strings as hexadecimal values
by jpl (Monk) on Mar 22, 2011 at 13:22 UTC

    Perhaps I am missing something. Why would it be "impossible" to have a format item "Y" (where "Y" is some unused format character, finding which may be the real problem) such that 

      pack("Y4", 32);       # produces "0020"
  unpack("Y4", "0020"); # produces 32

    [download]

    There are many format characters, v among them, that pack integers into strings and unpack strings into integers. I believe the only practical difference between "Y" and "v" is the contents of the string. The one produced by "v" may be unsuitable for display, the one produced by "Y" would be both displayable and, when displayed, indicative of the bits in the integer from which it was produced.

[reply]
[d/l]

      Actually, now you put it that way, I'm wrong. It could work and would be useful. It would be a departure from the norm of converting numerics to and from their binary representation.

      There are some issues as to what should happen if you specified pack 'Y4', 100000; or pack 'Y4', 32.0 but actually that perhaps suggests a way around the lack of remaining letters that also has an existing precedent.

      To skip a complex structure--say consisting of 2 shorts and float--the syntax is X[vvf], meaning skip enough bytes to cover 2 shorts and a float. Ie. 2+2+4 = 8 bytes.

      To get your hexified numeric, the syntax could be pack 'H[v]', 32, meaning treat the number as a a 16-bit int and hexify it; thereby producing your 4 bytes of output.

      The nice thing is that this then extends naturally to pack 'H[V]', 32; to produce 8-bytes of hex. And pack 'H[Q]', 123456789012345; and even pack 'H[f]', 1234.56e78; and so on.

      And once that is accepted, this further extends to the other bain of pack/unpack; binary. With 'B[v] b[V} B[d]' etc. And a quick peruse of the docs suggest that 'O' isn't currently used, so maybe 'O[v] O[Q]' might be useful also.

      Now all you've got to do is: knock up the patch; get it by p5p; and wait for it to make it into a build :)

      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.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom