in reply to Re^3: pack/unpack 6-bit fields. (precision)
in thread pack/unpack 6 bit fields.

Thanks. I keep forgetting how broken un/pack are in this respect. Having "B6" load the high six bits (of the low byte of the integer) is just non-sensical.

So for the most sane configuration (bits split based on base-2 representation not some "ascending bit order" representation) you have to work harder:

my @fields= unpack "C*", # 16 6-bit numeric values pack "b6"x16, # string of 16 bytes, each holding a 6-bit value map ''.reverse, # 16 6-character ascending-bit strings unpack "a6"x16, # 16 6-character base-2 strings unpack "B*", # 96-character base-2 string "twelve bytes"; # 12-byte packed string print "(@fields)\n"; my $string= pack "B*", # 12-byte packed string pack "a6"x16, # 96-character base-2 string map ''.reverse, # 16 6-character base-2 strings unpack "b6"x16, # 16 6-character ascending-bit strings pack "C*", # string of 16 bytes, each holding a 6-bit value @fields; # 16 6-bit numeric values print "($string)\n";


(29 7 29 37 27 7 25 37 8 6 9 57 29 6 21 51) (twelve bytes)

- tye        

Replies are listed 'Best First'.
Re^5: pack/unpack 6-bit fields. (Different types of sanity)
by BrowserUk (Patriarch) on Aug 18, 2004 at 19:48 UTC

        My numbers look correct to me.

        print unpack 'B*', 'twelve bytes'; ## hand spaced 001011 101110 111010 100110 001101 100110 111010 100110 000001 000100 011010 011110 001011 101010 011011 001110

        You show code containing 'B*' but the bits that you show are from using 'b*'. That is why you can match the 'b*' case against it.

        Trying to match the 'B*' against that string gives one of the less-sane results I mentioned (where the bit orders are mismatched).

        To be extra clear, using 'B*' would result in each group of 8 bits being reversed (it doesn't reverse the whole bit string), which results in different 6-bit chunks not just reversed 6-bit chunks (so neither of your cases cover it).

        - tye