перл и три бага
Oct. 18th, 2003 06:19 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaСегодня один из классических багов Перла привёл к тому, что в только что созданные журналы/коммьюнити невозможно было отправить записи, в течение 5 часов примерно. То есть баг не самого перла как языка, а типичный баг в программах на нём: в данном случае, путаница между 0 и undef.
Однако, несмотря на такие баги, отдельное значение undef в Перле себя оправдало, по-моему.
Другой типичный баг, который время от времени всплывает в исходниках ЖЖ, связан с тем фундаментальным фактом, что в Перле нет отдельных типов строк и чисел; скаляр в Перле может содержать целое число, или действительное число, или строку, и переводить одно в другое в зависимости от контекста. Но это значит, в частности, что проверка if("0") не проходит, т.к. "0" это то же самое, что 0, т.е. false. Для строк, возможно, удобнее было бы иметь другой критерий истинности, при котором любая непустая строка истинна, а пустая - ложна, но не получается. Из-за забывания этого иногда получаются баги.
Третий баг возникает как раз вследствие единственного нарушения вышеописанного принципа. Оператор & (двоичный and) действует по-разному в зависимости от того, что расположено внутри скаляров, на которые он действует: числа или строки.
Почему результаты разные? Потому что & действует на двоичное представление скаляра, не пытаясь привести его к канонической форме (которая в данном случае должна быть численной, конечно). Когда выполняется 12 & 5, выходит двоичный and между 1100 и 0101; результат - 0100, 4. Когда же выполняется "12" & "5", происходит двоичный and между ASCII-представлением строки "12", т.е.
00110001 00110010 , и ASCII-представлением строки "5", т.е. 00110101 . В результате выходит то же, самое, что "1" & "5", т.к. второму байту строки "12" ничего не соответствует в строке "5"; а
"1" & "5" выходит 00110001, т.е. "1", что корректно преобразуется при надобности в 1.
Таким образом, "x" & "y" и x & y дают одинаковый результат, если x и y - цифры от 0 до 9 (это выходит благодаря тому, что ASCII-представления цифр 0..9 начинаются с 48, т.е. совпадают с самими цифрами в четырёх последних двоичных регистрах), но если числа выходят за предел 0..9, результаты выходят разными.
Особенно больно это бьёт по разработчику, если он использует & для вычисления двоичной маски секьюрити, скажем, в целях обеспечения привилегированного доступа к какому-то объекту. Если при этом его числа, с которыми он делает &, на самом деле не числа, а в данный момент строки (например, потому, что их вернул модуль доступа к БД, всегда возвращающий строки, или Перл их внутри перевёл в строки для какой-то операции, того же print), то результат операции будет неверен, и легко может случиться так, что непривилегированный юзер получит доступ к объекту (всё это касается и двоичного or, кстати, т.е. оператора |, но он используется намного реже на практике, так что редко случаются баги с ним).
Четвёртый... пусть будет на баг, а kludge довольно забавный внутри Перла.
Цитируя документацию функции ioctl:
То же верно ещё для нескольких функций, являющихся перловскими обложками для системных функций: они возвращают обычно результат системной функции или undef в случае ошибки, но, если системная функция возвращает 0 и это для неё не ошибка, они возвращают "0 but true", таким образом пытаясь предотвратить второй баг, описанный выше: если неосторожный разработчик напишет
if(ioctl(...)), то это сработает, т.к. "0 but true" истинно, в отличие от "0"; а если нужно перевести в числовой контекст, то "0 but true" переведётся в 0:
Но если мы запускаем perl с опцией -w (warnings), то обычно перевод строки с не-числовым "мусором" в число выдаёт предупреждение:
А со строкой "0 but true" это не происходит, как и обещано в документации выше:
И это верно только для этой строки. На уровне исходников Перла это происходит так. В файле sv.c, имплементирующем операции со скалярами (sv=scalar value), есть функция looks_like_number(). Её вызывают, когда нужно определить, можно ли перевести данную строку в число; она смотрит на строку, и возвращает ноль, если эта строка не представляет из себя число, и ненулевое значение в обратном случае, причём тогда она возвращает значение, указывающее на то, какую функцию надо использовать для перевода данной строки в число (atol() для целых чисел, atof() для действительных). И вот, в этой функции, когда она уже проверила, выглядит ли строка как целое или действительное число, и вернула соответствующие значения в таких случаях, и уже совсем готова возвращать 0, указывая на неудачу, там стоит:
Классический пример того, что по-английски называют kludge, по-моему.
Однако, несмотря на такие баги, отдельное значение undef в Перле себя оправдало, по-моему.
Другой типичный баг, который время от времени всплывает в исходниках ЖЖ, связан с тем фундаментальным фактом, что в Перле нет отдельных типов строк и чисел; скаляр в Перле может содержать целое число, или действительное число, или строку, и переводить одно в другое в зависимости от контекста. Но это значит, в частности, что проверка if("0") не проходит, т.к. "0" это то же самое, что 0, т.е. false. Для строк, возможно, удобнее было бы иметь другой критерий истинности, при котором любая непустая строка истинна, а пустая - ложна, но не получается. Из-за забывания этого иногда получаются баги.
Третий баг возникает как раз вследствие единственного нарушения вышеописанного принципа. Оператор & (двоичный and) действует по-разному в зависимости от того, что расположено внутри скаляров, на которые он действует: числа или строки.
$ perl -e 'print 12 & 5;' 4 $ perl -e 'print "12" & "5";' 1
Почему результаты разные? Потому что & действует на двоичное представление скаляра, не пытаясь привести его к канонической форме (которая в данном случае должна быть численной, конечно). Когда выполняется 12 & 5, выходит двоичный and между 1100 и 0101; результат - 0100, 4. Когда же выполняется "12" & "5", происходит двоичный and между ASCII-представлением строки "12", т.е.
00110001 00110010 , и ASCII-представлением строки "5", т.е. 00110101 . В результате выходит то же, самое, что "1" & "5", т.к. второму байту строки "12" ничего не соответствует в строке "5"; а
"1" & "5" выходит 00110001, т.е. "1", что корректно преобразуется при надобности в 1.
Таким образом, "x" & "y" и x & y дают одинаковый результат, если x и y - цифры от 0 до 9 (это выходит благодаря тому, что ASCII-представления цифр 0..9 начинаются с 48, т.е. совпадают с самими цифрами в четырёх последних двоичных регистрах), но если числа выходят за предел 0..9, результаты выходят разными.
Особенно больно это бьёт по разработчику, если он использует & для вычисления двоичной маски секьюрити, скажем, в целях обеспечения привилегированного доступа к какому-то объекту. Если при этом его числа, с которыми он делает &, на самом деле не числа, а в данный момент строки (например, потому, что их вернул модуль доступа к БД, всегда возвращающий строки, или Перл их внутри перевёл в строки для какой-то операции, того же print), то результат операции будет неверен, и легко может случиться так, что непривилегированный юзер получит доступ к объекту (всё это касается и двоичного or, кстати, т.е. оператора |, но он используется намного реже на практике, так что редко случаются баги с ним).
Четвёртый... пусть будет на баг, а kludge довольно забавный внутри Перла.
Цитируя документацию функции ioctl:
The return value of "ioctl" (and "fcntl") is as follows:
if OS returns: then Perl returns:
-1 undefined value
0 string "0 but true"
anything else that number
Thus Perl returns true on success and false on failure, yet you
can still easily determine the actual value returned by the
operating system:
$retval = ioctl(...) || -1;
printf "System returned %d\n", $retval;
The special string "0 but true" is exempt from -w complaints
about improper numeric conversions.
То же верно ещё для нескольких функций, являющихся перловскими обложками для системных функций: они возвращают обычно результат системной функции или undef в случае ошибки, но, если системная функция возвращает 0 и это для неё не ошибка, они возвращают "0 but true", таким образом пытаясь предотвратить второй баг, описанный выше: если неосторожный разработчик напишет
if(ioctl(...)), то это сработает, т.к. "0 but true" истинно, в отличие от "0"; а если нужно перевести в числовой контекст, то "0 but true" переведётся в 0:
$ perl -e 'print "0 but true" + 5;' 5
Но если мы запускаем perl с опцией -w (warnings), то обычно перевод строки с не-числовым "мусором" в число выдаёт предупреждение:
$ perl -w -e 'print "12garbage" + 5;' Argument "12garbage" isn't numeric in addition (+) at -e line 1. 17
А со строкой "0 but true" это не происходит, как и обещано в документации выше:
$ perl -w -e 'print "0 but true" + 5;' 5
И это верно только для этой строки. На уровне исходников Перла это происходит так. В файле sv.c, имплементирующем операции со скалярами (sv=scalar value), есть функция looks_like_number(). Её вызывают, когда нужно определить, можно ли перевести данную строку в число; она смотрит на строку, и возвращает ноль, если эта строка не представляет из себя число, и ненулевое значение в обратном случае, причём тогда она возвращает значение, указывающее на то, какую функцию надо использовать для перевода данной строки в число (atol() для целых чисел, atof() для действительных). И вот, в этой функции, когда она уже проверила, выглядит ли строка как целое или действительное число, и вернула соответствующие значения в таких случаях, и уже совсем готова возвращать 0, указывая на неудачу, там стоит:
if (len == 10 && memEQ(sbegin, "0 but true", 10))
return IS_NUMBER_TO_INT_BY_ATOL;
return 0;
Классический пример того, что по-английски называют kludge, по-моему.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-10-18 06:27 pm (UTC)К стати, вот вы говорите "Все нормальные люди сравнивают результат ioctl с enumeration" когда здесь в соседмен thread говорят что его сравнивают с 0 или -1! Значит здесь много "ненормальных" сидят?
в Java можно downcast then ignore
Если специально вредить, то ничего ен поможет. Но если язык заставляет что-то сделать, то скорее всего это сделают правильно. Если определить все exceptions которые клиент обязан словить или упомянуть, то нет шансов что клиент просто поленился посмотреть какие exceptions могут быть вообще у данной финкции.
Ничего бы C не потерял. Записать 1 слово и проверить 1 слово будет незаметно. А если это делается в цикле, то компилятор может оптимизировать.
Perl знаю плохо -- на уровне простеньких програм. А опыт и размер софта над каким работаю -- так это Oracle RDBMS. Достаточно большая програмка ии нет? :) Поверьте, я мноо кода перечитал, включая код, который существовал уже лет 15 и актовно модифицировался. Иногда очень хочешь прибить кого-то за "фантазию".
Вот мой список из-за чего проблемы:
1. Функциональность, не покрытая тестами, которую вдруг начинают использовать
2. Изменения кода без понимания всех последствий (из-за слишком запутанного начального кода или плохой архитектуры).
Оба этих фактора могут быть вызваны корявым начальным кодом, в котором есть случаи что ни один тестер не предугадает (и может не напишет на это тест) и через 5 лет другой програмит тоже не будет знать (из-за чего поменяет нечто и что-то другое перестанет работать).
no subject
Date: 2003-10-19 01:03 am (UTC)Нормальные люди делают ошибки вне зависимости от языка
К стати, вот вы говорите "Все нормальные люди сравнивают результат ioctl с enumeration" когда здесь в соседмен thread говорят что его сравнивают с 0 или -1!
Его сравнивают с явной или неявной enumeration где -1 - это ошибка. А не используют как conditional (т.е. 0/не 0)
Вот мой список из-за чего проблемы ..
Ну, и какой пункт из этого списка завист от того, на каком языке написано? ;-)
no subject
Date: 2003-10-19 08:09 am (UTC)Да, но в каком количестве? Прежде чем отвечать, можно ведь было потратить 30 секунд чтобы задуматься над этим вопросом и, может засунуть его в google. Тогда было бы всё сразу понятно. Ладно, это сделал я. Вот самая первое что google возвращает на: "compare rate programmer errors per line of code Java".
Его сравнивают с явной или неявной enumeration где -1 - это ошибка.
??? Да у вас-же на глазах убсуждают: if( ioctl(...) == 0 ) или if( ioctl(...) != 0 ) или if( ioctl(...) ) или if( ioctl(...) == -1 )
Проблема #1. ioctl использует int как ресультат вместо enum.
Проблема #2. Даже если бы он использовал enum, C разрешил бы сравнивать с int всё равно.
И ещё, я может C полохо знаю, но понятия implicit enum в языке нет. ;)
И опять ещё. Я считаю это большой проблемой C то что люди (см выже) заботятся сильно а таких вещах как "надо ли != 0 писать или лучше опустить". Язык должен быть строже.
какой пункт из этого списка завист от того, на каком языке написано
#2. Корявый исходный код и плохая архитектура. Чем более "вольный" язык -- тем больше корявого кода. Если в языке нет неких базовых концептов и принципов -- тем хуже архитектура (на пример exceptions, objects, ...)
no subject
Date: 2003-10-19 10:53 am (UTC)The experiment used one programmer, one C++ project
and one Java project.
за это сразу двойку ставят, это не результат вообще ;-)
no subject
Date: 2003-10-19 01:16 pm (UTC)no subject
Date: 2003-10-19 01:36 am (UTC)Ничего бы C не потерял. Записать 1 слово и проверить 1 слово будет незаметно. А если это делается в цикле, то компилятор может оптимизировать.
(ну не слово, конечно)
C бы потерял нишу эффективного языка. Это не незаметно. На современных процессорах
*p++ = *q++ если каждый раз проверять, что поинтер не вышел за границу будет дольше на порядок. И это было бы везде
a->10 - надо проверять
a[10]=b[2] - надо проверять два раза
char* p = q+2 - тут вообще надо пересчитывать ограничение, которое было у q и записывать его для p.
Учитывая, что обычно C программы и состоят из такого, то смысла в таком C просто не будет - можно сразу уже переходить на Java/C#
no subject
Date: 2003-10-19 08:24 am (UTC)*p++ = *q++
лучще выглядят как
p[i] = q[i]; i++;
Компилятор запросто разберётся как это оптимизировать. И проверка границы массива тоже будет оптимизирована запросто если это делается в цикле.
На надо
char* p = q+2;
без этого можно запросто обойтись. Используй имя массива и индех в него вместо ссыкли в его середину. Или, ещё вариант, если оечнь хочешь ссылку в середину массива, хорошо, но тип "массив данных такого типа" должен отличаться от типа "ссылка на данные такого типа". Таким образом арифметика ссылок разрешена только с типом "массив" а не со случайной "ссылкой".
no subject
Date: 2003-10-19 10:44 am (UTC)Таким образом арифметика ссылок разрешена только с типом "массив" а не со случайной "ссылкой".
Вот я и говорю - из языка убирается произвольная поинтерная арифметика. То что остается - это как раз Java, зачем мне тогда такой "C'?
no subject
Date: 2003-10-19 12:37 pm (UTC)Да. Абсолютно произвольная поинтерная арифметика убирается. Остаётся "ограниченная (лимитированная) арифметика". Главный вопрос -- будет ли этого достаточно для всего или нет? Я думаю что будет. А до Java здесь о-очень далеко. Я не предлагаю "garbage collection".