Re^4: pack/unpack 6-bit fields. (insanity)

[tye]

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";

outputs:

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

[BrowserUk]

[tye]

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).