18 октября 2016 г., 22:50 пользователь Ivan Petrov
<i.petro.77...@gmail.com> написал:
>>> к какому улучшению?
>>> имеется туева хуча кода работающего с языками которая полагается на то
>>> что 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
> moscow-pm@pm.org | http://moscow.pm.org
-- 
Moscow.pm mailing list
moscow-pm@pm.org | http://moscow.pm.org

Ответить