in reply to Re: Re: H2 pack/unpack not working for negative numbers
in thread H2 pack/unpack not working for negative numbers

Before you can decide, or we can help you decide, which format specifier is the correct one to use, you will need to know how the information you are trying to unpack was packed.

For example, you mention an integer. An integer could be

  1. An 8-bit integer (byte),
    • signed (-128 .. +127)
    • unsigned (0 .. 255)
  2. A 16-bit integer (2 bytes/1 word)
    • Signed (-32768 .. 32767 )
    • Unsigned (0 .. 65535)
  3. A 32-bit integer (4 bytes/2 words/dword/long)
    • Signed (-2147483648 .. 2147483647)
    • Unsigned (0 .. 4294967295)
  4. A 64-bit integer (8 bytes/4 words/quadword/long long (etc!)) ....

There are other formats but these are the most common.

Add to this, the possibility that some machines pack binary values into words in different (byte) orders. So called litte-endian and big-endian and with the exception of 1) above, you can double each of those possibilities, which is why pack/unpack have so many format specifiers for "integers": N n V v S s C c.

Which you need to use could be any of these, but as a guess, s, n, & v seem the most likely candidates. H seems the least likely.

In other words. You need to supply more information:)

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
  • Comment on Re: Re: Re: H2 pack/unpack not working for negative numbers

Replies are listed 'Best First'.
Re: Re: Re: Re: H2 pack/unpack not working for negative numbers
by Anonymous Monk on Dec 10, 2003 at 23:44 UTC
    I was hoping to spare you the gory details, but...
    This is coming from a proprietary closed platform called "Flex/OS" by IBM which is a stripped down OS/2 for retail registers running on x86 pc's. I have no choice in how the data is packed. I believe the application treats everything as strings or numbers. I cracked IBM's infamous "packed decimal compressed transaction logs" with an elaborate perl program (which works better than several other expensive commercial programs we have seen). All the data fields in this file are either ascii or packed decimal. Perhaps they chose wrong in deciding to pack a negative number, I was just hoping to find someway to unpack it correctly. Sadly, there are other fields which are correctly unpacked as "d1".
    Kyle
[reply]

      OS/2 eh. That's my old stomping ground.

      Anyway, if you would post a small sample, encoded using MIME::Base64, along with a description of what you think the sample represents, I'll have a go at it. No guarentee's I'll do any better than you of course.

      You can encode the sample using 

      perl -mMIME::Base64=encode_base64 -000e" print encode_base64( <> )" 
   < sample >sample.b64

      [download]

      and then paste it in a code block here.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      Hooray!
[reply]
[d/l]

In Section Seekers of Perl Wisdom