<div dir="ltr">Не вижу проблемы, да, что-то изменили, но перед тем как обновляться, стоит ИМХО почитать change log и еще раз подумать, а точно ли надо обновляться?</div><br><div class="gmail_quote"><div dir="ltr">ср, 19 окт. 2016 г. в 1:09, Victor Efimov <<a href="mailto:victor@vsespb.ru">victor@vsespb.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">18 октября 2016 г., 22:50 пользователь Ivan Petrov<br class="gmail_msg">
<<a href="mailto:i.petro.77.00@gmail.com" class="gmail_msg" target="_blank">i.petro.77.00@gmail.com</a>> написал:<br class="gmail_msg">
>>> к какому улучшению?<br class="gmail_msg">
>>> имеется туева хуча кода работающего с языками которая полагается на то<br class="gmail_msg">
>>> что decode_utf8 не выбросит ексепшена на валидном юникоде.<br class="gmail_msg">
>>> приходит эстет (зачеркнуто) гей и вместо того чтобы поправить<br class="gmail_msg">
>>> документацию и зафиксировать в ней текущее положение вещей,<br class="gmail_msg">
>>> исправляет, меняет зафиксированное до этого на более чем 15 лет<br class="gmail_msg">
>>> поведение!<br class="gmail_msg">
><br class="gmail_msg">
>> Ну так как ты не читал документацию к Perl и твой код - один сплошной<br class="gmail_msg">
>> баг, то улучшение и исправление багов в perl вызывают поломку твоего<br class="gmail_msg">
>> кода. Ты при этом настолько профнепригоден, что не можешь этого понять<br class="gmail_msg">
>> и даже MR с описанием фикса не наводят тебя на мысль, что ты что-то<br class="gmail_msg">
>> делаешь не так.<br class="gmail_msg">
><br class="gmail_msg">
> MR с описанием фикса чего?<br class="gmail_msg">
> там чисто эстетический "фикс". Который более правильно назвать<br class="gmail_msg">
<br class="gmail_msg">
Это не эстетический фикс, это фикс реального бага, пример тест-кейза здесь<br class="gmail_msg">
<a href="https://rt.cpan.org/Public/Bug/Display.html?id=87267#txn-1250086" rel="noreferrer" class="gmail_msg" target="_blank">https://rt.cpan.org/Public/Bug/Display.html?id=87267#txn-1250086</a><br class="gmail_msg">
<br class="gmail_msg">
> поломкой.<br class="gmail_msg">
> Если 15+ лет одна из базовых функций ведет себя определенным образом,<br class="gmail_msg">
> то менять ее поведение НЕЛЬЗЯ.<br class="gmail_msg">
> см. Например спор Дреппера с Линусом Торвальдсом: первый говорил<br class="gmail_msg">
> - мои эстетические чуйства требуют изменить поведение memcpy,<br class="gmail_msg">
> а второй говорил<br class="gmail_msg">
> - но имеется 100500 кода, который полагается на текущее (более<br class="gmail_msg">
> чем 25 лет постоянное) поведение и эту вашу эстетику надо засунуть в<br class="gmail_msg">
> одно место. И вообще у меня видео из за вашей эстетики поломалось!<br class="gmail_msg">
<br class="gmail_msg">
Сравнение с этим случаем не корректное:<br class="gmail_msg">
1) в случае с линуксом идёт речь о том чтобы сделать workaround в<br class="gmail_msg">
багжному коду юзеров, ничего не сломав,<br class="gmail_msg">
в нашем случае ничего не сломать нельзя (оно и было сломано до этого фикса)<br class="gmail_msg">
2) в случае с линуксом функция могла бы проверять что её вызывают с<br class="gmail_msg">
неправильными данными, она этого не делала. в нашем<br class="gmail_msg">
случае проверка не возможна - в этом суть юникода perl - нельзя в<br class="gmail_msg">
общем случае отличить текст от бинарных данных (да, utf8 флаг ничего<br class="gmail_msg">
не говорит<br class="gmail_msg">
о том текст это в юникоде или нет). Хотя.. это сложно объяснить как<br class="gmail_msg">
раз русскоязычному юзеру, ибо такие проблемы только с Latin1<br class="gmail_msg">
3) в линуксе в роли юзеров у которых memcpy "иногда глючит" (из-за<br class="gmail_msg">
того что оптимизация intel иногда проявляла себя) были юзеры после<br class="gmail_msg">
внесения изменения, а в нашем случае, как раз "иногда глючило" до<br class="gmail_msg">
внесения изменения (иногда - если у строки появлялся utf8 флаг, это<br class="gmail_msg">
программист плохо контроллирует, он<br class="gmail_msg">
может появляться "случайно")<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> в итоге видео чинили месяцев этак шесть по репозитариям. А в ядре<br class="gmail_msg">
> линукс memcpy ведет себя по старому и никто от этого не страдает.<br class="gmail_msg">
> а код в ядерных модулях, который мог бы сломаться из за подобного<br class="gmail_msg">
> эстета (зачеркнуто) гея, не ломается.<br class="gmail_msg">
> --<br class="gmail_msg">
> Moscow.pm mailing list<br class="gmail_msg">
> <a href="mailto:moscow-pm@pm.org" class="gmail_msg" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" rel="noreferrer" class="gmail_msg" target="_blank">http://moscow.pm.org</a><br class="gmail_msg">
--<br class="gmail_msg">
Moscow.pm mailing list<br class="gmail_msg">
<a href="mailto:moscow-pm@pm.org" class="gmail_msg" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" rel="noreferrer" class="gmail_msg" target="_blank">http://moscow.pm.org</a><br class="gmail_msg">
</blockquote></div>