>> Нарушен в следствии полного следования ПДД каждым участником движения. Каждый реагировал
>> на входящую информацию строго по книжке. То что была нарушена дистанция
>> стало известно уже пост-фактум. В то время как когда полностью следуешь
>> стандарту -- всё будет хорошо.
> Либо "полное следование ПДД", либо "была нарушена дистанция", но не одновременно. ПДД
> не рассматривает "входные данные" - там всё равно, по какой причине
> вы не соблюдали дистанцию. Поэтому непосредственный виновник(и) всегда определяем(ы).

Замечательно. А теперь объясните мне (тупому) где тут противоречье с тем, что написал я? — «Каждый реагировал на входящую информацию строго по книжке».

Есть разница между тем, чтобы определять своё поведение в соответствии с какими-то правилами (то есть следовать им), и тем, чтобы не допустить ниодного нарушения ниодного из правил.

Второе просто невозможно, в то время, как первое возможно в ПДД (как я его себе представляю). Дак вот если каждый будет добросовестно делать как написано в стандарте — это будет гарантией работы кода (при верном компиляторе), а вот если каждый будет делать как написано в книжке по ПДД, то в результате будет авария.

Следовать правилам и соблюдать их — вещи разные, хоть и похожие. Грубо говоря, следование правилам может привести в ситуацию, где авария ещё не произошла, но где её уже не избежать. То есть, грубо говоря, водители следовали правилам, но не соблюли их.

И я очень прошу, не надо спорить на тему терминов. Тут сейчас важнее мысль, которую я пытаюсь донести, что этот эффект есть в ПДД, но нет в стандартах программирования. И если вы мою мысль поняли, то сейчас важно только это, а не то, что же знажчат слова «соблюдать» и т.п. в обычной терминологии.

>> Некорректная аналогия. Если меня собьют, это нельзя будет починить. Если же bind допустил ошибку, у них будет полно времени это починить.
> а) Не всегда сбивают насмерть.

Иногда сбивают — этого достаточно. А иногда необратимо калечат — этого тоже достаточно.

> б) Если bind ушёл к потребителям, и у кого-то упал - это
> уже произошло. Т.е. "откатить обратно" не получится.

Не надо было собирать bind с помощью самого свежего gcc «x.y.0» и сразу запускать в production. Собиралось старым gcc без проблем, вот им и собирай, пока не будешь уверен в том, что новая его версия тоже подходит. И вот как это выглядит с разных сторон:

1. Если ты автор bind-а, то тебе становится бесконечно стыдно после данной новости (см. изначальный subj), и ты быстро исправляешь проблему. После чего объявляешь, что bind можно безопасно собирать на gcc 4.9.z
2. Если ты просто maintainer, то ты тупо собираешь bind старым gcc до тех пор, пока не станешь уверен, что можно безопасно использовать новый gcc для этого говнокода. Если же ты уже push-нул дырявый bind в массы, то значит тебе тоже должно стать бесконечно стыдно за собственный идиотизм, и ты быстро push-аешь security update.
3. Если ты системный администратор, который решил установить необкатанный bind себе на машину и тебя хакнули, то ССЗБ.

*4. Кстати говоря, bind уже давно среди моих знакомых считается решетом. Ничего удивительного, что проблема возникла именно с ним.

>> So what? Опять же причём тут разработчики gcc?
> Давайте отбросим наивность и будем рассуждать цинично. Мейнтейнеры дистрибутивов - люди
> ленивые, в массе своей они не будут проверять список оптимизаций введённых
> в новую версию gcc. Они, если не будет сообщений пользователей или
> какого-то хайпа, просто перекомпилируют свой софт с новым gcc и -O2
> по-умолчанию.

Перекомпилируют софт с gcc «x.y.0»? Что-то я очень сомневаюсь. Может разве что arch какой-нибудь, но они как раз ССЗБ. Вы могли например заметить, что в Gentoo gcc 4.9.0 является замаскированным на данный момент. Как вы думаете, почему?

1. Ошибка в bind-е _уже_ была, однако в силу случайного стечения обстоятельств (то есть в силу особенностей gcc), она себя никак не проявляла. И тут эта ошибка тупо проявилась. Кто тут виноват? Только авторы bind-а и больше никто. Обвинять кого-то другого за то, что код ранее работал, хотя не должен был — это нелепо.
2. Анализ внешнего (относительно gcc) говнокода — это не задача разработчиков gcc.
3. Если кто-то использует последнюю версию gcc в production-е до обкатки на реальном ПО, то ССЗБ.
4. Многие важные проекты пытаются компилировать и другими компиляторами (и с другими реализациями библиотек), чтобы как раз в частности проверить на UB. Если bind этого не сделал, то опять же разработчики gcc тут не при чём.
5. Никто не запрещает смотреть changelog при каждом неминорном изминении gcc (коим и является данное). Что вы ещё-то хотите от разработчиков gcc?

Что конкретно вы хотите от gcc-шников. Как именно они должны подготавливать свои релизы по-вашему?

> Соответственно, с большой вероятностью, те оптимизации, которые gcc-шники вставляют в
> -O2, пройдут в софт без изменений. Т.е. gccшники имеют возможность непосредственно
> влиять на мировой софт. Это определённая власть.

So?

> Возвращаясь к maxima. Подобных проектов море. Во власти gcc-шников либо сделать их
> более хрупкими, либо менее хрупкими.

Хрупкими их делает не gcc, а качество их же собственного исходного кода. gcc как раз-таки в силу случайных обстоятельств давал возможность работать говнокоду, который _не должен был_ работать.

> При прочих равных более хрупкий код в эксплуатации хуже.

Ну дак не используйте bind.

> Есть власть => есть ответственность.

Да. И если бы gcc транслировал код в уязвимый в силу противоречия стандарту, то тогда это была бы ответственность разработчиков gcc. Но этот глюк вызван не неверной работой gcc, а неверным исходным кодом bind-а. Грубо говоря, это была именно их власть (разработчиков bind-а) допустить данную ошибку и ответственность за это тоже на них.

>> Если же вы хотите, чтобы он выводил какой-то дополнительный warning, то предложите это через maillist.
> Это уже сделано. И предупреждение будет.

Я говорил про подход, как бороться с такими проблемами в будущем.

>> 5 раз -- это далеко не предел. Надеюсь мы разобрались, что "-O0" -- это не синоним production-way?
> Перечитайте вопрос, пожалуйста. И ответьте на него.

Который вопрос? Этот? —

> Вы правильно всё поняли. Следовательно, debug мы компилируем с -O2, а release - с -O0? ;-)

Отвечаю: «Нет, не следовательно». Пояснения см. мой комментарий с моим изначальным ответом на данный вопрос.