18 октября 2016 г., 22:50 пользователь Ivan Petrov <[email protected]> написал: >>> к какому улучшению? >>> имеется туева хуча кода работающего с языками которая полагается на то >>> что decode_utf8 не выбросит ексепшена на валидном юникоде. >>> приходит эстет (зачеркнуто) гей и вместо того чтобы поправить >>> документацию и зафиксировать в ней текущее положение вещей, >>> исправляет, меняет зафиксированное до этого на более чем 15 лет >>> поведение! > >> Ну так как ты не читал документацию к Perl и твой код - один сплошной >> баг, то улучшение и исправление багов в perl вызывают поломку твоего >> кода. Ты при этом настолько профнепригоден, что не можешь этого понять >> и даже MR с описанием фикса не наводят тебя на мысль, что ты что-то >> делаешь не так. > > MR с описанием фикса чего? > там чисто эстетический "фикс". Который более правильно назвать
Это не эстетический фикс, это фикс реального бага, пример тест-кейза здесь https://rt.cpan.org/Public/Bug/Display.html?id=87267#txn-1250086 > поломкой. > Если 15+ лет одна из базовых функций ведет себя определенным образом, > то менять ее поведение НЕЛЬЗЯ. > см. Например спор Дреппера с Линусом Торвальдсом: первый говорил > - мои эстетические чуйства требуют изменить поведение memcpy, > а второй говорил > - но имеется 100500 кода, который полагается на текущее (более > чем 25 лет постоянное) поведение и эту вашу эстетику надо засунуть в > одно место. И вообще у меня видео из за вашей эстетики поломалось! Сравнение с этим случаем не корректное: 1) в случае с линуксом идёт речь о том чтобы сделать workaround в багжному коду юзеров, ничего не сломав, в нашем случае ничего не сломать нельзя (оно и было сломано до этого фикса) 2) в случае с линуксом функция могла бы проверять что её вызывают с неправильными данными, она этого не делала. в нашем случае проверка не возможна - в этом суть юникода perl - нельзя в общем случае отличить текст от бинарных данных (да, utf8 флаг ничего не говорит о том текст это в юникоде или нет). Хотя.. это сложно объяснить как раз русскоязычному юзеру, ибо такие проблемы только с Latin1 3) в линуксе в роли юзеров у которых memcpy "иногда глючит" (из-за того что оптимизация intel иногда проявляла себя) были юзеры после внесения изменения, а в нашем случае, как раз "иногда глючило" до внесения изменения (иногда - если у строки появлялся utf8 флаг, это программист плохо контроллирует, он может появляться "случайно") > > в итоге видео чинили месяцев этак шесть по репозитариям. А в ядре > линукс memcpy ведет себя по старому и никто от этого не страдает. > а код в ядерных модулях, который мог бы сломаться из за подобного > эстета (зачеркнуто) гея, не ломается. > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
