Не вижу проблемы, да, что-то изменили, но перед тем как обновляться, стоит ИМХО почитать change log и еще раз подумать, а точно ли надо обновляться?
ср, 19 окт. 2016 г. в 1:09, Victor Efimov <[email protected]>: > 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 >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
