красивые грабли, с ручкой, украшенной лепниной (C) dma

[dil]

Задача: прочитанные их файла байтики разобрать на отдельные биты. На перле.
Пишем простенькую тестовую программу:
#!/usr/bin/perl -w

my $foo = "\x47";

for(my $i=7;$i>=0;$i--){
print vec($foo, $i, 1)." ";
}
print "\n";

Получаем ожидаемое 0 1 0 0 0 1 1 1.

Поскольку байтиков ожидается больше одного, усложняем пример. Разбираем буфер на отдельные байты в массив:
my @a = unpack("C*", $foo);

проверяем, что получилось:
printf("0x%x\n", $a[0]);
(даёт 0x47, как и ожидалось)

и повторяем процедуру извлечения битов:
for(my $i=7;$i>=0;$i--){
print vec($a[0], $i, 1)." ";
}
print "\n";
и.. получаем другой результат: 0 0 1 1 0 1 1 1

Долго бьёмся головой об стену в тщетных попытках понять, почему три бита из восьми инвертировались.


работает, если vec() применять к chr($a[0]) или если unpack делать с A*

Спасибо dma, а то бы я голову разбил.

Comments

[http://users.livejournal.com/mak_/]

(не вникая в вопрос)мммм... а что, перл что-то гарантировал?

[tejblum.livejournal.com]

Не совсем понимаю, что такое "гарантии", однако о том, что функция vec ведет себя именно так, написанно в ее документации, причем в самом начале (если ее внимательно читать).

[dil.livejournal.com]

ага. только при этом надо постоянно помнить про автоматические преобразования целых чисел в строки и обратно. кто ж знал, что C - это не строка..

[tejblum.livejournal.com]

Все же, если оно через printf "0x%x" печатается как 0x47, то наверное это число 0x47, а не строка "\x47".

Меня в свое время в перле глубоко впечатлил тот факт, что

   foo(bar("baz"))

и

   my $x = bar("baz");
   foo($x)

-- разные вещи, и от замены второго на первое программа вполне может сломаться. Головой об стенку не бился, но впечатление было сильным.

[dil.livejournal.com]

потому что там ещё есть понятие контекста, скалярного или векторного..

[tejblum.livejournal.com]

Во-во, точно. Напридумывали фичей для удобства, блин.

[dil.livejournal.com]

а я разве писал, что кто-то что-то гарантировал?