Доступны корректирующие выпуски DNS-сервера BIND 9.10.0-P2 (http://permalink.gmane.org/gmane.network.dns.bind.announce/502), 9.9.5-P1 (http://permalink.gmane.org/gmane.network.dns.bind.announce/501) и 9.8.7-P1 (http://permalink.gmane.org/gmane.network.dns.bind.announce/500), в которых устранена серия уязвимостей и решена проблема (https://kb.isc.org/article/AA-01167), способная привести к краху процесса в непредсказуемые моменты обработки запросов. Примечательно, что проблема проявляется только при сборке с использованием GCC 4.9.0 и более новых выпусков и вызвана изменением работы оптимизатора GCC. В частности, начиная с GCC 4.9 по умолчанию включается режим удаления лишних операций сравнения с указателями NULL, при использовании которого из-за удаления из кода важных для работы проверок в BIND начинают проявляться непредсказуемые проблемы в работе. Для решения проблемы следует обеспечить сборку BIND с опцией "CFLAGS=-fno-delete-null-pointer-checks".Кроме отмеченной проблемы, в новых выпусках устранена порция DoS-уязвимостей:
- CVE-2014-3859 (http://permalink.gmane.org/gmane.network.dns.bind.announce/499) (только BIND 9.10) - крах при обработке специально оформленных EDNS-пакетов (механизм работы с пакетами, размером более 512 байт);
- CVE-2014-3214 (только BIND 9.10) - крах в процессе использования технологии prefetch;
- CVE-2013-6230 (только BIND 9.9) - ошибочный расчёт нулевых масок в localnets acl на платформе Windows;
- CVE 2014-0591 (только BIND 9.9) - крах при обработке некоторых подписанных зон NSEC3.URL: http://permalink.gmane.org/gmane.network.dns.bind.announce/499
Новость: http://www.opennet.me/opennews/art.shtml?num=39992
>удаления лишних операций сравнения с указателями NULL,
>при использовании которого из-за удаления из кода важных для работы проверок в BIND начинают проявляться непредсказуемые проблемы в работе.я чего-то не понял - это баг гцц ? Или как лишние сравнения, могут одновременно важными?
volatile
Оптимизатор не удалит. Ну или тогда это баг в gcc, да.
> я чего-то не понял - это баг гцц ? Или как лишние
> сравнения, могут одновременно важными?очень просто: стандарты не читай @ на си пиляй!
стандарт, в котором есть подобные UB, конечно, куча дурнопахнущего гуано, а не стандарт, но раз уж выбрали такой язык — соблюдайте.
если компилятор удалил проверку и «всё пропало, шеф, всё пропало!» — то это 99.(9)% вероятность не ошибки в компиляторе, а того, что на вход компилятору подали некорректный говнокод, полагающийся на то, что UB совсем не UB.
> режим удаления лишних операций сравнения с указателями NULLКакая чудесная оптимизация.
Модные мальчики пробрались в команду GCC.
Это нормальная оптимизация. И, как правильно сказали выше, ломается на ней именно [censored]код.
Если кода не очень много - чтобы его мог вычитать и вылизать один человек (или несколько достаточно близко контактирующих) - тогда да. А когда контрибутит большое сообщество, плюс либы от третьей стороны - прилететь может всё что угодно, поэтому проверять данные надо.
Переформулирую - код, который ты не вычитал сам, считай априори [censored]кодом, и допускай, что на выходе от него можно получить значение NULL там, где оно не может быть NULL.
man "code review"Во всех крупных свободных проектах. Если вы не применяете — никто вам не виноват.
Ладно, предположим, проверил я код всех сторонних либ, которые юзает мой проект. Нашёл "недоработку". Отправил багрепорт, может быть даже с патчем. А тот проект пилит один анонимус в своё свободное время, и реакции на багрепорт - никакой. Если я знаю, что везде, где мой софт будет использоваться, стоит эта либа с непофиксенным багом, из-за которого может прилететь NULL где не надо, что делать? Форкать либу и пропихивать свой форк в дистрибы? Включать в тарбол её исходники со своим фиксом? Я всё-таки выберу поставить в нескольких местах проверку на NULL, пусть это и не согласуется с чьими-то представлениями о красоте.
для начала — прекратить использовать неподдерживаемые библиотеки. как раз потому, что в них никто не чинит баги.впрочем, говнокодеры о таких нюансах никогда не думают, хватают первое попавшееся и радуются. недолго, правда.
Главное - заранее угадать какая библиотека станет неподдерживаемой завтра.Опыт и интуиция to the rescue
> Главное - заранее угадать какая библиотека станет неподдерживаемой завтра.не так уж и сложно, на самом деле.
>> режим удаления лишних операций сравнения с указателями NULL
> Какая чудесная оптимизация.Нормальная оптимизация.
Foo *foo = ...
foo->bar;
if (foo) ...;Вот последнюю проверку компилятор вполне имеет право удалить, ибо foo не может быть нулём, тогда foo->bar было бы обращением по нулевому указателю, а это UB, и компилятор волен обрабатывать как хочет. Делать вид, что обращений по нулевому указателю не бывает, например, и, следовательно, foo всегда не ноль.
> Вот последнюю проверку компилятор вполне имеет право удалитьВ мире эльфов - да. Всё-таки, вера в то, что компилятору не придётся обрабатывать код с ошибками, в высшей степени наивна.
> В мире эльфов - да. Всё-таки, вера в то, что компилятору не
> придётся обрабатывать код с ошибками, в высшей степени наивна.Есть баланс между толерантностью к ошибкам и качеством оптимизации. Включаешь оптимизатор — будь готов к тому, что кривой код он не простит.
Ну и статический анализ специально для этого придумали. clang'овский static-analyzer такие вещи отлично находит.
> Есть баланс между толерантностью к ошибкам и качеством оптимизации. Включаешь оптимизатор — будь готов к тому, что кривой код он не простит.Ну так -O3 уже никто и не включает. Или пацаны хотят добиться, что и -O2 включать не будут?
Баланс, разумеется есть, но gcc регулярно шагает за баланс в сторону оптимизации. Нижеприведённый код qsort в стандарт был введён в 1999 году, а на C писали и до этого года. Т.е. оптимизация ярковыраженно ломает нормальный код, написанный 20 лет назад.
Причём, как это обычно у gccшников, без объявления войны. Хотя бы предупреждения о выбрасывании кода можно было выкинуть. Ну, типа unreachable code.
>> Есть баланс между толерантностью к ошибкам и качеством оптимизации. Включаешь оптимизатор — будь готов к тому, что кривой код он не простит.
> Ну так -O3 уже никто и не включает. Или пацаны хотят добиться,
> что и -O2 включать не будут?Включаю -O3 в продакшене на корректно написанном коде, брат жив.
> Баланс, разумеется есть, но gcc регулярно шагает за баланс в сторону оптимизации.
Есть у меня один знакомый, который как раз поэтому gcc и обожает, что там код работает на 5-10% быстрее, чем в clang, как правило.
> Нижеприведённый код qsort в стандарт был введён в 1999 году, а
> на C писали и до этого года. Т.е. оптимизация ярковыраженно ломает
> нормальный код, написанный 20 лет назад.-std=c90 или подобное никто не запрещает передавать. Если при этом gcc откуда-то возьмёт требование к ненулёвости соответствующего аргумента qsort — вот тогда это проблема и баг в gcc. А если авторы пишут на C до 99 года, а передают ключи, соответствующие более свежему стандарту — ну, чо, ССЗБ.
> Причём, как это обычно у gccшников, без объявления войны. Хотя бы предупреждения
> о выбрасывании кода можно было выкинуть. Ну, типа unreachable code.Unreachable code в этом случае выкидывать — это либо прокидывать какой коллбек из optimization pass в морду, что, вполне возможно, с текущей архитектурой gcc фиг сделаешь, либо делать полноценный статический анализ на этапе разбора кода, а это на времени компиляции скажется не очень позитивно.
Да и вообще, на этапе оптимизации, как правило, довольно много кода может выкидываться, передвигаться, и так далее. На всё это ворнингами плеваться — их столько появится, что никто эту простыню читать не будет.
А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями — это к clang :)
> Включаю -O3 в продакшене на корректно написанном коде, брат жив.Я очень рад за вас и вашего брата. Но таки вы - исключение. Стандартные флаги оптимизации в дистрибутивах (т.е. в 99% открытого софта) - O2.
> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
> что там код работает на 5-10% быстрее, чем в clang, как
> правило.Про clang пока даже речи не было. Совершенно неизвестно, что тамошние бравые парни наворотили. Есть отдельные места - http://clang.llvm.org/doxygen/ToolChains_8cpp_source.html
которые заставляют несколько усомниться в их квалификации.> Да и вообще, на этапе оптимизации, как правило, довольно много кода может
> выкидываться, передвигаться, и так далее. На всё это ворнингами плеваться —
> их столько появится, что никто эту простыню читать не будет.Есть такое. Но если место столь неприятно опасное, то стоило бы.
> А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями —
> это к clang :)Он совершенно никакого сравнения с PVS-кой не выдерживает.
>> Включаю -O3 в продакшене на корректно написанном коде, брат жив.
> Я очень рад за вас и вашего брата. Но таки вы -
> исключение. Стандартные флаги оптимизации в дистрибутивах (т.е. в 99% открытого софта)
> - O2.Ну, это дело другое, и я бы на самом деле поспорил, что дело именно в ломающем код оптимизаторе. Впрочем, это оффтопик.
>> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
>> что там код работает на 5-10% быстрее, чем в clang, как
>> правило.
> Про clang пока даже речи не было. Совершенно неизвестно, что тамошние бравые
> парни наворотили. Есть отдельные места - http://clang.llvm.org/doxygen/ToolChains_8cpp_source.htmlКакой-то файл с костылями, честное слово.
> которые заставляют несколько усомниться в их квалификации.Да, там тоже есть свои проблемы. Но, по опыту, для кода, написанного по стандартам, а не по gcc, clang лучше себя ведёт.
>> А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями —
>> это к clang :)
> Он совершенно никакого сравнения с PVS-кой не выдерживает.У меня совершенно обратный опыт. Гонял один товарищ PVS по кое-чему из моего кода, ни единого сообщения по делу. В основном ругается на 32 и прочие подобные константы, считая это хардкодом битности машины, в коде вроде
auto pixmap = icon.pixmap (32, 32);
Ну и местами предлагает T на const T& заменить, не всегда по делу. Итого, сложилось впечатление, что это какая-то мешанина на регекспах, а не статический анализатор кода на плюсах.
clang'овский static-analyzer же, в свою очередь, несколько действительно проблемных мест мне нашёл.
> Ну, это дело другое, и я бы на самом деле поспорил, что
> дело именно в ломающем код оптимизаторе. Впрочем, это оффтопик.А в чём ещё? Какой смысл ставить -O2, если -O3 быстрее и не ломает код?
> Какой-то файл с костылями, честное слово.
Ну достаточно элементарного понимания, что такое дистрибутивы Linux'а, чтобы не писать подобных скриптов не просто на C++, а даже на bash'е. Достаточно же одной символьной ссылки на gcc или макроса с расположением gcc в коде, поставленного мейнтейнером пакета clang.
> Ну и местами предлагает T на const T& заменить, не всегда по
> делу. Итого, сложилось впечатление, что это какая-то мешанина на регекспах, а
> не статический анализатор кода на плюсах.Да, отчасти на регекспах, отчасти стат. анализатор. Много положительных срабатываний.
> clang'овский static-analyzer же, в свою очередь, несколько действительно проблемных мест
> мне нашёл.У меня - ни одного.
> А в чём ещё? Какой смысл ставить -O2, если -O3 быстрее и
> не ломает код?Не всегда быстрее. Например, слишком агрессивное развёртывание циклов или инлайнинг может привести к тому, что меньше полезного кода будет помещаться в кеш со всеми вытекающими. А в рамках всей системы — так немного (а иногда и существенно) большие бинари могут привести к лишнему своппингу.
>> clang'овский static-analyzer же, в свою очередь, несколько действительно проблемных мест
>> мне нашёл.
> У меня - ни одного.Ну вот это PVS'ом не нашлось, например: https://github.com/0xd34df00d/leechcraft/commit/8b8156678474... , а кланг после вот этого вот я прямо зауважал. Хотя дело под год назад было, да.
Да и PVS очень плохо относился к C++11, было суммарно с дюжину файлов, где он упал. clang сдох всего на двух.
> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
> что там код работает на 5-10% быстрее, чем в clang, как
> правило.если код твоего знакомого работает на 10% быстрее в gcc, чем в шланге, за счёт таких оптимизаций, то у меня для него плохие новости: у него в коде куча лишних проверок, которые он почему-то не выкинул сам. наверное, это как раз тот случай, когда компилятор умнее человека.
обычно знакомым таких личностей, как ваш знакомый, сочувствуют. но вы, похоже, этим гордитесь.
>> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
>> что там код работает на 5-10% быстрее, чем в clang, как
>> правило.
> если код твоего знакомого работает на 10% быстрее в gcc, чем в
> шланге, за счёт таких оптимизаций, то у меня для него плохие
> новости: у него в коде куча лишних проверок, которые он почему-то
> не выкинул сам. наверное, это как раз тот случай, когда компилятор
> умнее человека.Не код моего знакомого. Он всякими там povray бенчмаркает.
> обычно знакомым таких личностей, как ваш знакомый, сочувствуют. но вы, похоже, этим
> гордитесь.Нечем тут гордиться. И не гордиться, впрочем, тоже.
> у него в коде куча лишних проверок, которые он почему-то не выкинул сам.вышепроцитированное — реакция школоты на assert()'ы, например.
> если код твоего знакомого работает на 10% быстрее в gcc, чем в шланге, за счёт таких оптимизаций, то у меня для него плохие новости: у него в коде куча лишних проверокЕсли код работает на 10% быстрее после выкидывания "лишних" проверок, то этот код практически целиком состоит из проверок.
$ traceroute 0xd34df00d
traceroute to 0xd34df00d (211.77.240.13) 211-77-240-13.adsl.fetnet.net
...
10 h33-192-72-155.seed.net.tw (192.72.155.33) 320.941 ms
...
> $ traceroute 0xd34df00d
> traceroute to 0xd34df00d (211.77.240.13) 211-77-240-13.adsl.fetnet.net
> ...
> 10 h33-192-72-155.seed.net.tw (192.72.155.33) 320.941 ms
> ...0xd34df00d.me трейсить надо.
> Ну так -O3 уже никто и не включает. Или пацаны хотят добиться,
> что и -O2 включать не будут?пацаны хотят, чтобы говнокодеры документацию читали сначала.
уж от тебя-то я не ожидал такой позиции.
> Причём, как это обычно у gccшников, без объявления войны. Хотя бы предупреждения
> о выбрасывании кода можно было выкинуть. Ну, типа unreachable code.Release Notes к gcc 4.9 почитайте. И Porting to, если вам мало.
>> Вот последнюю проверку компилятор вполне имеет право удалить
> В мире эльфов - да. Всё-таки, вера в то, что компилятору не
> придётся обрабатывать код с ошибками, в высшей степени наивна.И разработчики GCC вряд ли страдают этой верой.
Кстати, foo->bar компилятор тоже вправе удалить... >:-)
>> Вот последнюю проверку компилятор вполне имеет право удалить
> В мире эльфов - да. Всё-таки, вера в то, что компилятору не
> придётся обрабатывать код с ошибками, в высшей степени наивна.для идиотов есть режим -O0. в документации по gcc ясно написано, что корректность выхлопа оптимизатора гарантируется *только* для корректных программ. если авторы подсунули компилятору говнокод, то они сами и виноваты.
> корректность выхлопа оптимизатора гарантируется *только* для корректных программif (a) {
mtx.lock();
if (a) { // явно же лишняя проверка - только что проверили.
>> корректность выхлопа оптимизатора гарантируется *только* для корректных программ
> if (a) {
> mtx.lock();
> if (a) { // явно же лишняя
> проверка - только что проверили.конечно, лишняя. если ты меняешь переменную из разных потоков и не объявил её volatile — ты идиот, а твой код говно.
такие дела.
>>> корректность выхлопа оптимизатора гарантируется *только* для корректных программ
>> if (a) {
>> mtx.lock();
>> if (a) { // явно же лишняя
>> проверка - только что проверили.
> конечно, лишняя. если ты меняешь переменную из разных потоков и не объявил
> её volatile — ты идиот, а твой код говно.Не всё так просто, см. страницу 7 здесь: http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
Правда, то в приложении к синглтонам.
да, я в курсе, что volatile — не такая уж простая и лёгкая штука. ну, и welcome в область нестандартного — read and write barriers в gcc, например…
p.s. да, компилятор имеет право проанализировать метод lock(), увидеть, что a там не меняется и выкинуть проверку нафиг.
> if (a) {
> mtx.lock();
> if (a) { // явно же лишняя
> проверка - только что проверили.Ну так в C++ до 11 не было memory model, машина представлялась однопоточной. Это уже проблема языка и стандарта, а не компилятора.
премию обратно не отдадут =D
Премия-то - 2500$. Деньжища-то какие. ;)
я не понял, если это баг гцц, где патч? а если баг бинда, зафига этот костыль, вместо приведения кода в порядок?
Это похоже на универсальную закладку. Чтобы даже если программист все дыры закроет нужными проверками, всё равно в исполняемом файле дырочки бы остались.
> Это похоже на универсальную закладку. Чтобы даже если программист все дыры закроет
> нужными проверками, всё равно в исполняемом файле дырочки бы остались.Нет, это для удобства программиста, желающего поставить бэкдор. Написал volatile - и оппа, сразу дырочка, хотя формально проверка есть.
> Написал volatile - и оппа, сразу дырочка,Вы там с головой в дружбе? Volatile как раз наоборот запрещает компилеру optimize out то что по его мнению можно выбросить, т.к. явно хинтит что помеченное как volatile может изменяться или использоваться неожиданным для компилятора образом и соответственно выбрасывать это ни в коем случае нельзя.
Это не баг, просто компилятор не может, по компилируемому куску кода, самостоятельно определить, что эти переменные могут принять значение NULL. Почитай про ключевое слово volatile.
>volatileоткуда инфа, что виновато volatile? можно ссылочку? (ищу диффы, не могу найти)
Volatile не "виновато" а всего лишь указывает компилеру что переменная может изменяться неожиданным для него образом (в эмбедовке, например, обработчик прерывания может сильно сбоку туда что-то записать, etc) и что данную переменную по этому поводу нельзя удалять в целях оптимизации, даже если все выглядит так как будто она не используется.
> компилятор не может, по компилируемому куску кода, самостоятельно определить, что эти переменные могут принять значение NULLи поэтому удаляет код, который явно проверяет это и написан программистом, который МОЖЕТ это сделать самостоятельно. браво.
> написан программистом, который МОЖЕТ это сделать самостоятельноКак факт, замечу, что программист не всегда это делает. Допустим есть функция:
static inline int first(char *str)
{
return str ? str[0] : -1;
}
И вот примерчик её использования:
int char use_case()
{
char str[] = "Hello world";
return first(str);
}В этом примерчике, программист МОЖЕТ проверить на NULL самостоятельно, и может даже самостоятельно выкинуть эту проверку, заинлайнив first вручную. Но, вообще-то, inline функции для того и придумали, чтобы их инлайнил компилятор.
Зарубите себе на носу: программист -- это человек который крайне не любит делать что-либо самостоятельно, программист -- это человек, который уверен, что всё, что может быть автоматизировано, должно быть автоматизировано. Если человек в этом не уверен, то он не программист. В частности, если может быть автоматизировано выкидывание ненужных сравнений с нулём, то это должно быть сделано.
> Допустим есть функция:Я об этом как-то не подумал... хотя, ваш пример носит другой характер.
В вашем случае компилятор явно _видит_, что str!=NULL и выкидывает проверку в first. Это обычное вычисление констант на этапе компиляции.
В обсуждаемом же случае компилятор видит, что используется str[0], и _догадывается_, что str!=NULL и поэтому выкидывает проверку.
То есть в случае
static inline int first (char *str)
{
int ret = str[0];
if (!str) ret = -1;
return ret;
}компилятор выкидывает проверку !str, т.к. str[0] использовалось раньше. И в результате на системах, где чтение нулевого адреса не приведёт к ошибке, first() будет работать некорректно. Хоят с точки зрения программиста, от "высокоуровневого ассемблера" логично предполагать, что в этом случае функция либо выполнится правильно либо выдаст SIGSEGV. Компилятор же внёс вариант "выполнится успешно, но неправильно".
Не могу сказать, что я поощряю программистов, которые делают такие ошибки, но имхо такая оптимизация - не то же самое, что замена умножения сдвигом или jmp для хвостовой рекурсии.
ИМХО, идеальным вариантом стала бы поддержка какого-нибудь -fno-optimize-undefined-behavior, который бы просто не оптимизировал подобные сомнительные случаи, т.е. перекладывал бы "неопределённое поведение" на процессор и библиотечные функции.
> идеальным вариантом стала бы поддержка какого-нибудь -fno-optimize-undefined-behavior, который бы просто не оптимизировал подобные сомнительные случаи ...где ты *сомнительный* случай нашёл?
если программист сделал для структуры (foo)
x = foo->bar
// other codeзначит компилятор *БЕЗ* каких либо сомнений знает что foo всегда != 0.
> ИМХО, идеальным вариантом стала бы поддержка какого-нибудь -fno-optimize-undefined-behavior,
> который бы просто не оптимизировал подобные сомнительные случаи, т.е. перекладывал бы
> "неопределённое поведение" на процессор и библиотечные функции.есть такой ключ! -O0!
по Вашему ассемблер так вообще для слабаков.
> return str ? str[0] : -1;А это вообще нормально - возвращать str[0] который char как знаковый int? Нет, си конечно по факту так позволяет. Но, как бы это сказать, неаккуратненько...
> А это вообще нормально - возвращать str[0] который char как знаковый int?нормально, говнокодеры говорят малацца.
>> return str ? str[0] : -1;
> А это вообще нормально - возвращать str[0] который char как знаковый int?
> Нет, си конечно по факту так позволяет. Но, как бы это
> сказать, неаккуратненько...Ты знаешь назначение функции first? Видишь ли, при ней нет документационного комментария, поэтому я не знаю, для чего она вообще нужна. Если ты знаешь, расскажи мне, и мы обсудим, насколько уместно возвращение str[0].
нинасколько, потому что никакой разумной причины возвращать или str[0] или -1 нет, ибо -1 входит во множество значений char. неразумных же причин можно выдумать много, но все они могут возникнуть только в говнокоде.
> нинасколько, потому что никакой разумной причины возвращать или str[0] или -1 нет,
> ибо -1 входит во множество значений char. неразумных же причин можно
> выдумать много, но все они могут возникнуть только в говнокоде.Отлично. Тогда я предлагаю переписать тот примерчик, дабы продемонстрировать оптимизацию на идеологически верном коде. Удивите нас.
А что тут ненормального? Архитектур, где sizeof(char)==sizeof(int) уже и не осталось, разве что контроллеры какие-то. А для обычного рядового кода char, даже если он unsigned, в signed int поместится гарантированно.
> А что тут ненормального?как я уже писал, ненормально тут то, что -1 — валидное значение для char, который по умолчанию signed. как этот код ни переписывай, он изначально говнокод, потому что использует для исключительной ситуации код возврата, который может появиться и без исключительной ситуации. у программиста при виде этого в голове ревёт сирена. сразу. вне зависимости от того, может ли во входном потоке встретиться \xff — если это никак не проверяется, и даже комментария нет, то может, и встретится, и всё сломается.
это как не проверять результат malloc'а: глаз мгновенно спотыкается, а руки автоматически тянутся вставить хотя бы проверку с abort'ом.
> char, который по умолчанию signed.Нет, знаковость char зависит от платформы.
>> char, который по умолчанию signed.
> Нет, знаковость char зависит от платформы.на большинстве платформ у большинства компиляторов char по‐умолчанию знаковый. без явных дополнительных уточнений это принимается умолчанием.
clang пусть используют
> clang пусть используютПорождение клятiх яблочников и вообще неправославно.
яблочники делали предложение команде gcc по обьединению
А до этого делали предложение Столлману идти ***** со своей GPL v3 и, что характерно, Линус тоже не перешел.
> Линус тоже не перешел.Гражданин судья, а он не может перейти! :)
Для перехода ядра на GPLv3 нужно получить согласие у всех авторов коммитов в ядро за всю его историю. Долететь до Альфы Центавра будет быстрее и проще.
> Что за милая, чудесная, универсальная GPLv3, не правда ли? Ну и ее
> предшественница - так-то не сильно лучше.Если бы некоторые не очень хорошие личности не находили лазейки в GPLv2 то и GPLv3 не требовался бы. Скажем тивоизаторам и прочим мошенникам спасибо, хренли. Как известно, если в законе закручивают гайки, этому обычно предшествует абуз какой-то фичи до состояния когда спокойно жить становится невозможно.
> Как известноЭто был новый некрософт-батыр. Мозгом не оснащён, дискутировать бесполезно, зачищаю.
> Это был новый некрософт-батыр.Ну вот, блин, опять меня бот на дискуссию развел :(.
я таки не понял, вам нравится, что GPLv3 требует согласия всех авторов или нет?
Мы просто найдем аналоги без GPL
> Мы просто найдем аналоги без GPLвперёд. не понятно только, зачем «вы» при этом лезете в обсуждения gpl-ного софта со своими истериками.
> Мы просто найдем аналоги без GPLДа, аналог линевому кернелу уж так искали, так искали. Только даже опач и яху задолбались искать чего-то. Бизибокс тоже грозились переписать. Года наверное 3 прошло, а воз и ныне там. Так и приходится бедным несчастным вендорам GPL tarball публиковать...
> А до этого делали предложение Столлману идти ***** со своей GPL v3если у таких отпетых проприерастов, как огрызок, GPLv3 вызывает настолько большие анальные неудобства, то это лишний раз доказывает, что GPLv3 хорошая.
> яблочники делали предложение команде gcc по обьединениюДа, особенно хорошо все это заметно на примере swift, где они вообще не знают будет ли это опенсорсным. А оно надо - с такими объединяться?
Представляю, какое богатство лексикона продемонстрирует Линус, если выяснится, что ядро, собранное новым GCC ведёт себя не так, как должно.
> Представляю, какое богатство лексикона продемонстрирует Линус, если выяснится, что ядро,
> собранное новым GCC ведёт себя не так, как должно.и по делу, само собой. то есть, напрямую тем идиотам, которые закомитили код, полагающийся на UB.
Правильный баг, вместо выполнения кода вылетает приложение :)
Просто не нужно собирать критические программы с помощью gcc версии x.y.0.
Ну кто-то Арч юзает, не в продакшне конечно, но все-таки неприятно.
> Ну кто-то Арч юзает, не в продакшне конечно, но все-таки неприятно.А википедия вообще на убунте :)
Да много кто на убунте, на самом деле. На 14.04 все-таки 4.8.х используется, 4.9 опционально.
На самом деле, в убунте много других поводов для веселья.
В Убунту на серваках зато гигантское комьюнити. И если не хочешь придумывать велосипеды и тестировать их у себя в продакшне,то это сейчас неплохой выбор, особенно если все завязано на средства автоматизации типа чефа, паппета и т.д, где есть куча всего готового именно под Убунту.
Сам, скрипя сердцем, в собственных поделках стал использовать Убунту вместо Опенсюзи из-за этого где-то год назад. :(
> В Убунту на серваках зато гигантское комьюнити.К сожалению, произведение количества участников коммьюнити на их средний уровень профессионализма - величина постоянная. Иными словами, чем больше коммьюнити - тем ниже уровень технической грамотности в нем.
> На самом деле, в убунте много других поводов для веселья.А в чем они состоят? А то у меня на ряде серверов она пашет уже пятый год. Проблем - ноль.
Не нужно писать код, не соответствующий стандартам:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236#c8
И всё будет хорошо.The glibc prototype for qsort is:
extern void qsort (void *__base, size_t __nmemb, size_t __size,
__compar_fn_t __compar) __nonnull ((1, 4));
therefore when you pass x to it, gcc derives from that that x must not be NULL.
As ISO C99 says that qsort sorts an array of nmemb objects, I'd say the glibc prototype is correct and therefore BIND is buggy, because NULL is not an address of any object.
> Не нужно писать код, не соответствующий стандартамИ вообще нужно быть красивым, здоровым и богатым.
Ну и, я так понимаю, с точки зрения авторов GCC до 1999 года код на языке Цэ не писали.
Очевидно, что код до 99 года компилировали другими версиями GCC.И потом, хочешь оптимизаций - пиши по стандартам, хочешь писать как угодно, не проси компилятор исправлять твой говнокод.
> Очевидно, что код до 99 года компилировали другими версиями GCC.Очевидно, компилятор языка с полувековой историей имеет определённые обязательства по поддержанию совместимости.
> И потом, хочешь оптимизаций - пиши по стандартам, хочешь писать как угодно,
> не проси компилятор исправлять твой говнокод.Солнце, до 99-го года этого стандарта не было.
а так же генерировать максимально быстрый код.
Разработчики предпочти второе.
> а так же генерировать максимально быстрый код.
> Разработчики предпочти второе.Всегда можно сгенерировать мгновенно выполняющийся нерабочий код. :-)
{
return 0;
}Очень быстрый код :). Компилер неплохо оптимизнет, наверное.
Ну так для совместимости есть специальные ключи. А если декларируется C99, то о чём речь?
> Ну так для совместимости есть специальные ключи. А если декларируется C99, то
> о чём речь?О том, что лучше не плодить несовместимость на ровном месте.
> Ну и, я так понимаю, с точки зрения авторов GCC до 1999
> года код на языке Цэ не писали.какое отношение авторы gcc имеют к glibc? ты что, перепил вчера, что ли?
> Просто не нужно собирать критические программы с помощью gcc версии x.y.0.собираю, брат жив, батя грит малацца.
просто надо сначала выучить язык, на котором пишешь, потом прочитать документацию на тулчейн, а только потом писать.
Как компилятор мог сломать программу?
И какой самый без ошибок? Clang?
> Как компилятор мог сломать программу?
> И какой самый без ошибок? Clang?Кланг, при всей моей любви к нему, тоже обожает подобные оптимизации.
> И какой самый без ошибок? Clang?Clang? Без ошибок? Б$%, это ты не видел что LLVM вытворяет при сборке шейдеров для AMDшного драйвера. Там вообще адов багодром и полный сталинград. По милости этого глюкала постоянно вылетают программы которые им пользуются. Вообще, хорошее поведение для либы - не сообщить наверх "ну не смогла я, не смогла!" а просто вылететь нафиг, срубив при этом всю программу. Это в лучшем случае. В хучшем это гуано выдаст некорректный код который повесит GPU, что доставит много радости юзверю за монитором :)
дооптимизировались. "режим удаления лишних операций" теперь удаляет не только лишние операции, но и нужные.
фтопку такой компилятор, который собирает не тот код, который написал программист, а тот, который, по его мнению, хотел написать программист
> фтoпку такой компилятор, который собирает не тот код, который написал программист, а
> тот, который, по его мнению, хотел написать программистА других нынче и нет.
Точнее, есть, но они используются только для узкоспецифичных задач.
> тот, который, по его мнению, хотел написать программистНу тогда используйте компиляторы без оптимизаторов. Ну там tiny c compiler какой-нибудь. Правда, качество кодогенерации вам не понравится...
> дооптимизировались. "режим удаления лишних операций" теперь удаляет не только лишние операции,
> но и нужные.нет, только лишние. а вот почему дебилы, которые даже не удосуживаются выучить язык, на котором пишут, называют себя «программисты» — это уже другой вопрос.
короче говоря, вот ссылка на gcc'шную багзиллу: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236 (Status: RESOLVED INVALID)суть в том, что в qsort передается переменная-указатель, которая может быть NULL'ом.
с другой стороны эта функция промаркирована в glibc как такая, которая не может принимать NULL на входе (что соответствует стандарту). из этих соображений, gcc выводит, что в переменной не может быть NULL и убирает проверки.обещают в gcc 4.10.0 вывод предупреждения на подобные случаи
Вывод - в glibc такое assert'ами прикрывать надо. В более продвинутых языках он бы даже автоматом сгенерировался из атрибута nonnull, кстати. Наглядный пример неудобств слабой типизации сей.
> Вывод - в glibc такое assert'ами прикрывать надо.К.О. напоминает, что релизных сборках assert-ы не работают.
> К.О. напоминает, что релизных сборках assert-ы не работают.у людей, пишущих на "более продвинутых языках", любая сборка по определению отладочная.
Это в тех где все тормозит и ждет сотни мегабайт озу? (если не больше)
Так ничего не мешает отладочную выкладывать в качестве релиза.
Ясен пень, что не работают.
Это не первый такой баг. Помнится не так давно gcc ломал сборку ядра или добавлял дыры убирая такие проверки.
> Это не первый такой баг. Помнится не так давно gcc ломал сборку
> ядра или добавлял дыры убирая такие проверки.Оптимизаторы вообще своеобразная штука, которая может подгадить.
> Оптимизаторы вообще своеобразная штука, которая может подгадить.Так к ним главное требование - не гадить.
> Так к ним главное требование - не гадить.Используйте -O0, только чур не плеваться на качество кода. А так - в данном случае оптимизатор формально прав. Как ни странно. Я конечно понимаю что у некоторых возникает батхерт, когда программы получаются умнее человека. Но это даже не столько заслуга программы, сколько недостаток человека, клавшего на стандарты с прибором и почему-то думавшего что undefined behavior будет работать именно так как ему удобно, а вовсе не...
>> Так к ним главное требование - не гадить.
> Используйте -O0, только чур не плеваться на качество кода. А так -
> в данном случае оптимизатор формально прав.Оптимизатор - это не субъект, чтобы быть правым. А вставивший это в него несколько безответственен.
Мало ли что формально разрешено. Скажем, в месте с undefined behavior формально можно вставить всё, что угодно, включая вызов "rm -rf $HOME". Однако, если не быть идиотом, понятно, что компилятор должен обрабатывать это максимально безопасно.
Это только в глубоком детстве кажется, что "вот мы напишем правила, и всё будет зашибись". Нет, люди нарушают правила, правила не учитывают все возможные ситуации и т.д. Поэтому есть такое понятие "культура". Вот у создателей компиляторов промышленных языков с 50-ти летним багажом должна быть определённая культура поддержания совместимости.
> Мало ли что формально разрешено. Скажем, в месте с undefined behavior формально
> можно вставить всё, что угодно, включая вызов "rm -rf $HOME". Однако,
> если не быть идиотом, понятно, что компилятор должен обрабатывать это максимально
> безопасно.Хочется такой безопасности и вождения за ручку — не надо называть себя программистами на C и писать на сях.
> Это только в глубоком детстве кажется, что "вот мы напишем правила, и
> всё будет зашибись". Нет, люди нарушают правила, правила не учитывают все
> возможные ситуации и т.д. Поэтому есть такое понятие "культура". Вот у
> создателей компиляторов промышленных языков с 50-ти летним багажом должна быть определённая
> культура поддержания совместимости.Культура есть. Флаг -std никто не отменял. Авторы проекта всё-таки, наверное, лучше компилятора знают, с каким стандартом у них кодовая база написана? И -std=c89 лично мне sane default'ом не кажется, например.
> Хочется такой безопасности и вождения за ручку — не надо называть себя
> программистами на C и писать на сях.Я давно за то, чтобы сбросить язык Цэ с парохода современности, как Фортран и ассемблер.
> Культура есть. Флаг -std никто не отменял. Авторы проекта всё-таки, наверное, лучше
> компилятора знают, с каким стандартом у них кодовая база написана? И
> -std=c89 лично мне sane default'ом не кажется, например.Ну, а теперь немного подумаем о том, как совместно собирать код, написанный до 99-го года и после. Скажем, вот вы в 2002-м году пишете программу, использующую заголовки из 1992-го.
> Я давно за то, чтобы сбросить язык Цэ с парохода современности, как
> Фортран и ассемблер.Современный Цэ++ вполне годен, не надо его сбрасывать.
Да и вообще, инструментом полезно уметь пользоваться, хоть джавой, хоть хаскелем.>> Культура есть. Флаг -std никто не отменял. Авторы проекта всё-таки, наверное, лучше
>> компилятора знают, с каким стандартом у них кодовая база написана? И
>> -std=c89 лично мне sane default'ом не кажется, например.
> Ну, а теперь немного подумаем о том, как совместно собирать код, написанный
> до 99-го года и после.Собирать часть с одним -std, часть — с другим. В C вроде даже вплоть до C11 нет проблем с разными ABI, не вижу проблемы.
> Скажем, вот вы в 2002-м году пишете программу, использующую заголовки из 1992-го.
Так исходная проблема-то в другом — там люди из 1992-го года писали программу, использующую заголовки из 2002-го. И это как раз решаемо вообще на раз-два. Обратная совместимость легче реализуема, чем forward.
> Современный Цэ++ вполне годен, не надо его сбрасывать.Синтаксис уже такой, что ужас. Увы, но Цэ++ уже давно ужасен.
> Собирать часть с одним -std, часть — с другим.
Ещё раз - директива #include включает заголовок, написанный до 99-го года.
> В C вроде даже вплоть до C11 нет проблем с разными ABI, не вижу проблемы.
Ну вот GCCшники успешно внесли проблему несовместимости.
> Так исходная проблема-то в другом — там люди из 1992-го года писали программу, использующую заголовки из 2002-го. И это как раз решаемо вообще на раз-два. Обратная совместимость легче реализуема, чем forward.
Каждый отдельный случай решается на раз-два. Проблема в том, что этих раз-два миллионы за 50 лет накопилось. И большая часть этих раз-два неизвестна.
>> Современный Цэ++ вполне годен, не надо его сбрасывать.
> Синтаксис уже такой, что ужас. Увы, но Цэ++ уже давно ужасен.Вполне типичный синтаксис для сиподобного языка.
>> Собирать часть с одним -std, часть — с другим.
> Ещё раз - директива #include включает заголовок, написанный до 99-го года.Системный инклюд? С чего бы.
Свой собственный, пользовательский — ну так разные стандарты языка и так могут быть не до конца совместимы.
>> В C вроде даже вплоть до C11 нет проблем с разными ABI, не вижу проблемы.
> Ну вот GCCшники успешно внесли проблему несовместимости.Не в ABI.
>> Так исходная проблема-то в другом — там люди из 1992-го года писали программу, использующую заголовки из 2002-го. И это как раз решаемо вообще на раз-два. Обратная совместимость легче реализуема, чем forward.
> Каждый отдельный случай решается на раз-два. Проблема в том, что этих раз-два
> миллионы за 50 лет накопилось. И большая часть этих раз-два неизвестна.Это как раз целый класс отдельных случаев, который и встретился в исходном посте. А что мы там обсуждаем инклюды 1992-го кода из 2002-го — это совсем другое дело, любопытное в качестве умственных разминок, но совершенно не имеющее отношения к исходной проблеме.
> Свой собственный, пользовательский — ну так разные стандарты языка и так могут
> быть не до конца совместимы.На поддержание совместимости стандартов тратятся огромные силы. Собственно, из-за этой совместимости языком Цэ++ и пользуются до сих пор. Да и вообще начали пользоваться.
Страшно подумать, что бы было, если бы Цэ/Цэ++ начал меняться как Бидон.
> Не в ABI.
Но тем не менее - стандарты 99/89 в этом месте совместимы, а gcc пока нет. Я не сомневаюсь, что и в этот раз кому надо дадут по мозгам и исправят проблему. Слишком много денег крутится вокруг gcc.
> Это как раз целый класс отдельных случаев, который и встретился в исходном
> посте.
> А что мы там обсуждаем инклюды 1992-го кода из 2002-го
> — это совсем другое дело, любопытное в качестве умственных разминок, но
> совершенно не имеющее отношения к исходной проблеме.За огромное кол-во лет накопилось всякое. А включение старых библиотек в новые проекты более чем естественно.
Тем не менее, это казуистика. А факт - gcc поломал совместимость стандартов 99 и 89.
> На поддержание совместимости стандартов тратятся огромные силы. Собственно, из-за этой
> совместимости языком Цэ++ и пользуются до сих пор. Да и вообще
> начали пользоваться.Не всегда. move semantics могут кое-какой код поломать (я на это сам натыкался, деталей не помню, правда), например.
> Но тем не менее - стандарты 99/89 в этом месте совместимы, а
> gcc пока нет.Почему? Несовместимы. В более новом стандарте более сильные требования на параметры, как я понял. Какая же тут обратная совместимость?
> Не всегда. move semantics могут кое-какой код поломать (я на это сам
> натыкался, деталей не помню, правда), например.Могут. Это неприятно и очень дорого.
> Почему? Несовместимы. В более новом стандарте более сильные требования на параметры, как
> я понял. Какая же тут обратная совместимость?в ЭТОМ месте. Код 89-го года вполне компилируется с qsort 99-го.
> в ЭТОМ месте. Код 89-го года вполне компилируется с qsort 99-го.«Компилируется» — не значит «работает». Что мы и наблюдаем тут.
> «Компилируется» — не значит «работает». Что мы и наблюдаем
> тут.До "тут" он работал. Каждое такое место - это большие денежные потери на ровном месте (тяжёлый труд высококвалифицированных разработчиков, хорошо знающих С, по разгребанию старого кода).
> До "тут" он работал.И это большая удача, не более. Вообще, мы говорили о совместимости стандартов. Если новый стандарт налагает более серьёзные требования на значения аргументов, чем старый, то совместимым со старым его назвать нельзя. Это к тому, виноват gcc или нет, нарушил он совместимость или нет.
А что там деньги тратятся — ну да, тратятся. Но это в данном случае дело десятое.
> Если новый стандарт налагает более серьёзные требования на значения аргументов, чем
> старый, то совместимым со старым его назвать нельзя.Стандарты слишком сложны, чтобы быть 100% совместимыми. Уже введение нового ключевого слова поломает часть программ. Поэтому можно говорить лишь о большей и меньшей совместимости. В С/С++ её поддерживают значительно лучше, чем в том же Python'е.
> Тем не менее, это казуистика. А факт - gcc поломал совместимость стандартов
> 99 и 89.слушай, ну хватит уже, всё, не надо больше, я не могу столько смеяться!
> Вполне типичный синтаксис для сиподобного языка.Это лямбды-то? Шаблоны в современном применении - вообще ужас ужасный.
> Это лямбды-то?Чем [] (auto x, auto y) { return x + y; } сильно так сложнее (x, y) => x + y ?
Это для такого банального случая скобочек-палочек чуть больше у плюсов, а для сколь угодно нетривиальной лямбды различия ещё слабее.
Причём, в C++17 ЕМНИП есть пропозал, что auto в параметрах вообще можно будет не писать, будет полагаться по дефолту.
> Шаблоны в современном применении - вообще ужас ужасный.
В тривиальных случаях всё очень просто, а нетривиальные так не обязательны :)
> Чем [] (auto x, auto y) { return x + y; }
> сильно так сложнее (x, y) => x + y ?Какое отношение имеют скобки, означающие массив, к лямбда-функциям?
> Причём, в C++17 ЕМНИП есть пропозал, что auto в параметрах вообще можно
> будет не писать, будет полагаться по дефолту.Вывод типов предложили в 1969-м году. В С++ он не вставлен, по-видимому, из-за обратной совместимости с нестрого типизированным C.
> В тривиальных случаях всё очень просто, а нетривиальные так не обязательны :)
Тем не менее, выход за пределы тривиального случая преобразуется в ужас-ужас-ужас.
>> Чем [] (auto x, auto y) { return x + y; }
>> сильно так сложнее (x, y) => x + y ?
> Какое отношение имеют скобки, означающие массив, к лямбда-функциям?Эм, они вообще-то обозначают начало лямбды. Ну и какой массив обозначают скобки вида [x = std::move (y)] ?
> Вывод типов предложили в 1969-м году. В С++ он не вставлен, по-видимому,
> из-за обратной совместимости с нестрого типизированным C.Однако, C++ и так чуть более строго типизирован, чем C (например, void* к T* сходу не приведётся). Кроме того, вывод типов уровня auto и так уже есть, что-то вроде утиной типизации в темплейтах — тоже, а Хиндли-Милнера вы едва ли найдёте в хотя бы одном сиподобном языке. Хоть в джаве, хоть в C#, хотя им уж точно совместимость с C поддерживать не нужно.
Впрочем, там всё равно не вывод типов, а шаблонный operator(), соответствующий структуре-функтору, генерирующейся по лямбде.
> Тем не менее, выход за пределы тривиального случая преобразуется в ужас-ужас-ужас.
В 100% случаев выходить не обязательно. Да, нетривиальное применение шаблонов может существенно сэкономить время и количество строк кода, но ведь мощные инструменты не обязаны быть простыми.
> Эм, они вообще-то обозначают начало лямбды. Ну и какой массив обозначают скобки
> вида [x = std::move (y)] ?О! Вот это и вопрос - глаз видит скобки, 25 лет означающие массив, а реально там что-то другое.
> Однако, C++ и так чуть более строго типизирован, чем C (например, void*
> к T* сходу не приведётся).В 1986-м году основное требование - код на С должен компилироваться без проблем.
> а Хиндли-Милнера вы едва ли найдёте в хотя бы одном
> сиподобном языке.Ну и что? Разве это хорошо?
> Хоть в джаве, хоть в C#, хотя им уж
> точно совместимость с C поддерживать не нужно.Java и C#, по-видимому, устарели с самого своего появления.
> но ведь мощные инструменты не
> обязаны быть простыми.Чем проще, тем лучше при прочих равных. А С++ уже очень сложен.
>> Эм, они вообще-то обозначают начало лямбды. Ну и какой массив обозначают скобки
>> вида [x = std::move (y)] ?
> О! Вот это и вопрос - глаз видит скобки, 25 лет означающие
> массив, а реально там что-то другое.Я, конечно, не 25 лет пишу на плюсах, а всего лет 10, но глаз у меня видит начало лямбды.
>> а Хиндли-Милнера вы едва ли найдёте в хотя бы одном
>> сиподобном языке.
> Ну и что? Разве это хорошо?Да. Не знаю, как у вас, а у меня плохо получается представить себе императивный язык с Х-М и в то же время сиподобной системой типов. Х-М без каких-нибудь там тайпклассов и тому подобного не очень-то и полезен, ИМХО.
Хотя, конечно, бывает, пишешь очередной костыль с type erasure на плюсах, например, и очень сильно жалеешь об отсутствии экзистенциальных типов. Но это такое.
>> но ведь мощные инструменты не
>> обязаны быть простыми.
> Чем проще, тем лучше при прочих равных. А С++ уже очень сложен.И тут возвращаемся к тому, что в 100% случаев вся мощь темплейтов не обязательна.
> Я, конечно, не 25 лет пишу на плюсах, а всего лет 10,
> но глаз у меня видит начало лямбды.А у меня он сперва видит какую-то инициализацию массива, которую уже потом я воспринимаю, как лямбду. Т.е. читаемость значительно ухудшилась.
> Х-М без каких-нибудь там тайпклассов и тому подобного не
> очень-то и полезен, ИМХО.Так классы типов хотели ввести.
> Так классы типов хотели ввести.Эм, это где? Опять я всё пропустил.
>> Так классы типов хотели ввести.
> Эм, это где? Опять я всё пропустил.Так концепты.
>>> Так классы типов хотели ввести.
>> Эм, это где? Опять я всё пропустил.
> Так концепты.Ох, да им до тайпклассов таки… далеко, в общем.
Да и это для темплейтов всё равно. Ограниченный Х-М получится.
> Ох, да им до тайпклассов таки… далеко, в общем.
> Да и это для темплейтов всё равно. Ограниченный Х-М получится.auto тоже далеко до pattern matching'а. Увы, другого C++ у меня для вас нет - всё упирается в сложность языка и поддержку совместимости с имеющимся кодом.
> auto тоже далеко до pattern matching'а. Увы, другого C++ у меня для
> вас нет - всё упирается в сложность языка и поддержку совместимости
> с имеющимся кодом.Паттерн-матчинг в темплейтах есть уже сегодня. Ну, это если мы о темплейтах говорим.
Впрочем, конечно, если охота писать на каком-нибудь хаскеле, лучше писать на хаскеле, а не издеваться над бедными компиляторами и прочим тулчейном. Вон, gdb 7.7 от особо наркоманских шаблоновывертов успешно падает.
>> Эм, они вообще-то обозначают начало лямбды. Ну и какой массив обозначают скобки
>> вида [x = std::move (y)] ?
> О! Вот это и вопрос - глаз видит скобки, 25 лет означающие
> массив, а реально там что-то другое.нет, оказывается, всё ещё могу.
const int a[] = {1,2,42}.
глаз видит скобки, пол-века обозначающие «начало блока операторов или определений», а это на самом деле — инициализация массива. вот когда обоснуешь, почему тут скобки фигурные, а не квадратные — тогда можно будет продолжить по поводу лямбд и их скобок.
> глаз видит скобки, пол-века обозначающие «начало блока операторов или определений»,
> а это на самом деле — инициализация массива. вот когда обоснуешь,
> почему тут скобки фигурные, а не квадратные — тогда можно будет
> продолжить по поводу лямбд и их скобок.Молодец! Вот и я пишу, что с синтаксисом в Цэ++ полный трындец. Большое спасибо за пример.
> Молодец! Вот и я пишу, что с синтаксисом в Цэ++ полный трындец.
> Большое спасибо за пример.пожалуйста. правда, я привёл пример сишного синтаксиса, но так же неинтересно, это же окажется, что цпп просто следует традициям.
> пожалуйста. правда, я привёл пример сишного синтаксиса, но так же неинтересно, это
> же окажется, что цпп просто следует традициям.Цэ просто более-менее обозрим, хотя с синтаксисом уже плохо - см. ещё указатель на функцию. :-) А у ЦэПП уже полный Ԥ, потому как количество переходит в качество.
> Цэ просто более-менее обозрим, хотя с синтаксисом уже плохо - см. ещё
> указатель на функцию. :-) А у ЦэПП уже полный Ԥ, потому
> как количество переходит в качество.я вот недавно ещё страшнее вещь заметил: куча имён функций может начинаться на «p». ты представляешь, какой это ужас? ведь я как вижу «p», так сразу ожидаю, что там будет «printf»! а тут такой облом…
>> пожалуйста. правда, я привёл пример сишного синтаксиса, но так же неинтересно, это
>> же окажется, что цпп просто следует традициям.
> Цэ просто более-менее обозрим, хотя с синтаксисом уже плохо - см. ещё
> указатель на функцию. :-) А у ЦэПП уже полный Ԥ, потому
> как количество переходит в качество.Самое интересное, что в C++ это уже и не нужно вовсе, есть же std::function.
Хотя, конечно, если мы захотим передать лямбду в G_CALLBACK без временных переменных и тому подобного, то начнут вылезать всякие интересности вроде конструкций типа G_CALLBACK (+[] (...) { ... }). Плюсик тут прелестен, да.
> Самое интересное, что в C++ это уже и не нужно вовсе, есть же std::function.В С++ есть десятки способов реализовать одну и ту же задачу. Это одновременно и хорошо, и плохо.
> В С++ есть десятки способов реализовать одну и ту же задачу. Это
> одновременно и хорошо, и плохо.Как мне десятком способов передать замыкание в роли этакого коллбека или функтора? Я сходу только два придумал.
> Как мне десятком способов передать замыкание в роли этакого коллбека или функтора?
> Я сходу только два придумал.Если чутка обобщить задачу, получится - класс, шаблон, макрос, указатель на функцию.
> указатель на функцию. :-) А у ЦэПП уже полный Ԥ, потому
> как количество переходит в качество.Да, всякие слабаки уходят программить на яве и питоне. Поэтому программами на си++ даже пользоваться реально. Их писали настоящие программисты.
тебя кто-то жестоко обманул, когда сказал, что «настоящее программирование» — это анальные мучения с языком, придуманым идиотом и десятки лет развиваемым комитетом идиотов.
> тебя кто-то жестоко обманул, когда сказал, что «настоящее программирование»
> — это анальные мучения с языком, придуманым идиотом и десятки лет
> развиваемым комитетом идиотов.Анальные мучения там чаще всего возникают с реализацией. Чего далеко ходить, вот из моего сегодняшнего, например: http://0xd34df00d.point.im/nwddi
В языке местами тоже есть лажа и недоработки, но они либо из-за совместимости с С, либо фиксятся в следующих стандартах (вроде отсутствия std::future::then).
тут такое дело, что я просто на дух не переношу цпп. там ВСЁ плохо. особенно то, что пытались сделать хорошо.
>> указатель на функцию. :-) А у ЦэПП уже полный Ԥ, потому
>> как количество переходит в качество.
> Да, всякие слабаки уходят программить на яве и питоне.Не, туда уходят реально мужественные люди. На одном - шаблоны сделаны хуже, чем в C++, хотя и позже, а другой - это вечный слом API в сочетании с динамической типизацией.
> const int a[] = {1,2,42}.
> глаз видит скобки, пол-века обозначающие <<начало блока операторов или определений>>,
> а это на самом деле - инициализация массива. вот когда обоснуешь,
> почему тут скобки фигурные, а не квадратные - тогда можно будет
> продолжить по поводу лямбд и их скобок.Это значит что уже не важно что видит ваш глаз.
(инициализация массивов - далеко не нововведение в C)...
> Это значит что уже не важно что видит ваш глаз.иншалла! действительно, это всего лишь дело привычки, об этом я и писал.
> Ну, а теперь немного подумаем о том, как совместно собирать код, написанный
> до 99-го года и после. Скажем, вот вы в 2002-м году
> пишете программу, использующую заголовки из 1992-го.да запросто. раздельную компиляцию придумали ещё в прошлом веке.
> да запросто. раздельную компиляцию придумали ещё в прошлом веке.А читать тебя научили 30-40 лет назад. А всё равно, про включённые заголовки не прочёл.
>> да запросто. раздельную компиляцию придумали ещё в прошлом веке.
> А читать тебя научили 30-40 лет назад. А всё равно, про включённые
> заголовки не прочёл.прочёл. и что?
> прочёл. и что?Теперь вспоминаем, что такое раздельная компиляция.
>> прочёл. и что?
> Теперь вспоминаем, что такое раздельная компиляция.то, что я каждый день использую. там даже можно делать такие штуки, как подпихивать разным исходникам разные инклюды, представляешь? а потом собирать объектники в библиотеки и линковать код с этими библиотеками.
> то, что я каждый день использую.Молодец, правильно рассказал. А теперь представь, что у тебя есть замшелый софт (пост 99), использующий ещё более замшелые библиотеки (пре 99). Оно работает, ты просто его перекомпилируешь под систему. И, внезапно, на 4.9 получаем опа из-за оптимизации. И ты либо сидишь на древнем говно-Линуксе, либо тратишь тонны времени на отладку.
>> то, что я каждый день использую.
> Молодец, правильно рассказал. А теперь представь, что у тебя есть замшелый софт
> (пост 99), использующий ещё более замшелые библиотеки (пре 99). Оно работает,
> ты просто его перекомпилируешь под систему. И, внезапно, на 4.9 получаем
> опа из-за оптимизации. И ты либо сидишь на древнем говно-Линуксе, либо
> тратишь тонны времени на отладку.нет, у меня такого «внезапно» не бывает. потому что я немножко в курсе стандартов, в курсе поведения оптимизатора и в курсе того, что в «замшелом софте» с вероятностью 100% куча UB, поэтому прежде всего я буду собирать его с -O0, а уж потом — если надо — шерстить код на предмет того, что там следует починить в соответствии с нынешними реалиями.
> нет, у меня такого «внезапно» не бывает. потому что я немножко в
> курсе стандартов, в курсе поведения оптимизатора и в курсе того, что
> в «замшелом софте» с вероятностью 100% куча UB, поэтому прежде всего
> я буду собирать его с -O0, а уж потом — если
> надо — шерстить код на предмет того, что там следует починить
> в соответствии с нынешними реалиями.Ну ты возишься в своей маленькой песочнице, а кругом большой мир, где есть всякое. Оно хорошо, что ты делаешь качественно, но кругом бывает по-разному.
> Оно хорошо, что ты делаешь качественно, но кругом бывает по-разному.и я тебе таки скажу, что если продолжать делать подпорки для говнокода, то говнокод пребудет с нами вечно.
>> то, что я каждый день использую.
> Молодец, правильно рассказал. А теперь представь, что у тебя есть замшелый софт
> (пост 99), использующий ещё более замшелые библиотеки (пре 99). Оно работает,
> ты просто его перекомпилируешь под систему. И, внезапно, на 4.9 получаем
> опа из-за оптимизации. И ты либо сидишь на древнем говно-Линуксе, либо
> тратишь тонны времени на отладку.Или еще вариант: не пользуешься софтом за авторством людей, не знающих свои инструменты. Если человек включает хедеры пре99-версии языка, то он не имеет права писать код на пост99-версии языка, по крайней мере, без очень тщательной инспекции этих хедеров.
А оптимизаторы — дело тут десятое.
> Или еще вариант: не пользуешься софтом за авторством людей, не знающих свои
> инструменты.Ну это ты крут. Прелагаю тебе попробовать и выписать тут программы, которыми можно пользоваться. Ядро, я так понимаю, только l4.
Зачем? Можно на самом деле спокойно пользоваться и чинить баги, а не обвинять плохие компиляторы.
> Зачем? Можно на самом деле спокойно пользоваться и чинить баги, а не
> обвинять плохие компиляторы.Ну бред-то не надо писать, а? Берёте wc -l, исходники ядра, libc считаете кол-во строк и думаете, сколько вам времени понадобится на исправление ошибок.
> Ну бред-то не надо писать, а? Берёте wc -l, исходники ядра, libc
> считаете кол-во строк и думаете, сколько вам времени понадобится на исправление
> ошибок.А их так и так исправлять придется. Ошибка из исходного поста — так, индикатор отношения к стандартам, не более. Если есть такая ошибка, наверняка будет и множество других. Все из них отключением оптимизатора не «исправишь».
> А их так и так исправлять придется.Почему? У софта есть время жизни, после которого софт становится не нужен => больше ошибки в нём искать не нужно.
Типичный пример - игра Prince of Persia. После того, как он ушёл в антиквариат, в нём находили ошибки.
P.S.
Я не пишу про отключение оптимизатора, хоть предупреждение выбрасывайте.
> Почему? У софта есть время жизни, после которого софт становится не нужен
> => больше ошибки в нём искать не нужно.Какое время жизни у linux kernel или glibc, про которые шла речь в комментарии, на который я отвечал?
> Какое время жизни у linux kernel или glibc, про которые шла речь
> в комментарии, на который я отвечал?Ядро Линукса и glibc состоят из частей, которые периодически заменяются на другие. Поэтому, хотя время жизни целого весьма велико, время жизни каждой части вполне ограничено.
> Ядро Линукса и glibc состоят из частей, которые периодически заменяются на другие.
> Поэтому, хотя время жизни целого весьма велико, время жизни каждой части
> вполне ограничено.Тогда это вырождается во «взять и переписать», так критикуемое вами.
> Тогда это вырождается во «взять и переписать», так критикуемое вами.Не вырождается, т.к. там "две страницы вырванных выкладок".
То "взять и переписать", которое я ТАК критикую - это когда очевидные плюсы совершенно не смотрятся на фоне очевидных минусов. Тут же код "естественным образом" приходит и уходит. Старые, неиспользуемые драйвера выкинули, новые добавили, переписали сетевой стек для большей производительности и т.д. Одних планировщиков процессора в линуксе делали массу.
В случае Xorg и Wayland или init и systemd я не вижу плюсов от переписывания, зато вижу минусы. Могу раскрыть, если интересно, подробнее.
> Ну бред-то не надо писать, а? Берёте wc -l, исходники ядра, libc
> считаете кол-во строк и думаете, сколько вам времени понадобится на исправление
> ошибок.и поэтому ошибки чинить не будем: всё равно это нереально, не так ли? про декомпозицию, верификацию и прочие умные слова если и слышали, то давно и краем уха.
> и поэтому ошибки чинить не будем: всё равно это нереально, не так
> ли? про декомпозицию, верификацию и прочие умные слова если и слышали,
> то давно и краем уха.Арису, вернись из Валинора и убери ребёнка с компьютера. До 20-ти лет он не сможет понять, что мир не чёрно-белый. Ошибки, разумеется, чинить надо, но в зависимости от времени жизни, серьёзности софта и других параметров. В ряде случаев лучше сделать так, чтобы проявления ошибок были не столь разрушительны - вставить защиту памяти, защиту системы от rm -rf, запускать программу в песочнице и т.д.
знаешь, есть такое практическое наблюдение у меня: когда кто-то говорит про «нечёрнобелый мир», в подавляющем большинстве случаев он пытается этим замаскировать свою лень и рукожопие.такие дела.
> знаешь, есть такое практическое наблюдение у меня: когда кто-то говорит про «нечёрнобелый
> мир», в подавляющем большинстве случаев он пытается этим замаскировать свою лень
> и рукожопие.У вас, в Валиноре всё именно так, да. Возвращайся обратно, пожалуйста.
нет, спасибо, хрюкайте без меня.
> тратишь тонны времени на отладку.Если ты завинтил древнему коду мега-оптимизации не имея понятия о том насколько этот код следует стандартам и прочее - не очень понятно на кого тут можно жаловаться кроме самого себя. Оптимизатор имеет право делать все что угодно в рамках стандарта. А если кто полагался на UB - наверное это не оптимизатор виноват?
> Если ты завинтил древнему коду мега-оптимизацииТам в Makefile как было -O2, так и осталось. Только с увеличением версий gcc это -O2 стало означать несколько другое.
> Я давно за то, чтобы сбросить язык Цэ с парохода современности,Сбросьте.
> ассемблер.
А вон та пачка свежих коммитов в libvpx на хардкорном ассемблере с AVX и Neon - это вам как? Куда вы там кого сбросили? Хотя да, академики типа вас предложат нам запускать кодек VP9 на Cray, ведь у них под рукой есть - можно мувик для ютуба за разумное время компреснуть. А то что юзеры на писюках будут неделю ффтыкать на расово верный и безопасный, но жутко тормозной код - академиков не парит :).
> Скажем, вот вы в 2002-м году пишете программу, использующую заголовки из 1992-го.
Это, мягко говоря, довольно нишевой случай. И при столь экзотичном случае (криокамера разморозилась и програмер не заметил что прошло 10 лет?) - немного запатчить код может и придется.
>>> Так к ним главное требование - не гадить.
>> Используйте -O0, только чур не плеваться на качество кода. А так -
>> в данном случае оптимизатор формально прав.
> Оптимизатор - это не субъект, чтобы быть правым. А вставивший это в
> него несколько безответственен.
> Мало ли что формально разрешено. Скажем, в месте с undefined behavior формально
> можно вставить всё, что угодно, включая вызов "rm -rf $HOME". Однако,
> если не быть идиотом, понятно, что компилятор должен обрабатывать это максимально
> безопасно.:-) Не должен...
Это вам к любителям Java, скорее.
> Это только в глубоком детстве кажется, что "вот мы напишем правила, и
> всё будет зашибись". Нет, люди нарушают правила, правила не учитывают все
> возможные ситуации и т.д. Поэтому есть такое понятие "культура". Вот у
> создателей компиляторов промышленных языков с 50-ти летним багажом должна быть определённая
> культура поддержания совместимости.При чём здесь совместимость? С точки зрения C 80х годов всё обстоит отнюдь не лучше...
> думавшего что undefined behavior будет работать именно так как ему удобнопотому что всю жизнь ub относилось не к компилятору а к процессору. си был высокоуровневым ассемблером. и ub подразумевало, что компилятор скомпилирует как есть, а сможет ли это выполнить процессор - это уже и будет ub. и си-программисты это понимали. и смело использовали, например, (unsigned)-1 для получения максимального беззнакового целого числа на архитектурах типа x86, где это работало.
теперь же пришли "оптимизаторы", и наоптимизировали так, что си скатился в убогий паскаль, где без лишней головной боли нельзя даже преобразовать Integer в Word. программа это уже не инструкция компьютеру, что он должен сделать, а оправдательная записка компилятору, с просьбой разрешить выполнение алгоритма.
а по сути, современный "оптимизированный" /bin/sleep занимает 20КБ, хотя исходного кода там на 20 строк. зато соптимизировали лишние проверки, ага.
> потому что всю жизнь ub относилось не к компилятору а к процессору.
> си был высокоуровневым ассемблером. и ub подразумевало, что компилятор скомпилирует как
> есть, а сможет ли это выполнить процессор - это уже и
> будет ub.школоло, покажи эти слова в стандарте.
Ну очевидно же, что подобные штуки в стандартах не пишут. Точно также, как в УК не написано, что воровать плохо (только тюремные сроки).Т.е. если ты хочешь подтверждений тезиса, нужны статьи или рассуждения Кернигана и Ричи с объяснениями, что и зачем. Было бы неплохо, если бы предыдущий комментатор их предоставил.
> Ну очевидно же, что подобные штуки в стандартах не пишут.поэтому «подобные штуки» — не более чем досужие измышления.
> Точно также, как в УК не написано, что воровать плохо (только тюремные сроки).
это как раз потому, что воровать — не плохо, а уголовно наказуемо.
> Т.е. если ты хочешь подтверждений тезиса, нужны статьи или рассуждения Кернигана и
> Ричи с объяснениями, что и зачем.какое отношение k&r имеют к текущим стандартам?
> поэтому «подобные штуки» — не более чем досужие измышления.Естественно, нет. Вокруг каждого ЯП есть определённая культура - то, что плохо формализуется. То, что ты её не видишь, очень плохо.
> это как раз потому, что воровать — не плохо, а уголовно наказуемо.
А почему воровать уголовно наказуемо?
> какое отношение k&r имеют к текущим стандартам?
Если ты таки прочитаешь внимательно комментатора, которого несправедливо обосрал, ты поймёшь, что он писал про дела минувших дней.
>> поэтому «подобные штуки» — не более чем досужие измышления.
> Естественно, нет. Вокруг каждого ЯП есть определённая культура - то, что плохо
> формализуется. То, что ты её не видишь, очень плохо.Очень плохо ссылаться на плохо формализуемые вещи.
> Очень плохо ссылаться на плохо формализуемые вещи.??? В школе что-нибудь, кроме арифметики проходили?
>> Очень плохо ссылаться на плохо формализуемые вещи.
> ??? В школе что-нибудь, кроме арифметики проходили?Да, но последние N лет исключительно всякими формальными вещами занимаюсь. Профдеформация, видимо.
> Да, но последние N лет исключительно всякими формальными вещами занимаюсь. Профдеформация,
> видимо.Видимо. Потому, что есть масса нужных, но плохо формализуемых вещей, которыми мы пользуемся ежедневно. Таких, как, например, умение писать хорошо читаемый код, хорошо читаемые статьи.
>> поэтому «подобные штуки» — не более чем досужие измышления.
> Естественно, нет. Вокруг каждого ЯП есть определённая культура - то, что плохо
> формализуется. То, что ты её не видишь, очень плохо.естественно, да. то, что кучка людей договорилась чесать левое ухо и делать три приседания перед тем, как запускать компилятор — это их личная проблема и местечковый обычай. ни авторы компилятора, ни авторы библиотек не обязаны обращать внимание на местечковые обычаи, у них есть документ, которым они руководствуются. всё, что в этом документе не описано, они поддерживать не должны.
>> это как раз потому, что воровать — не плохо, а уголовно наказуемо.
> А почему воровать уголовно наказуемо?потому что общество так договорилось. впрочем, то же самое общество узаконило некоторые формы отнятия личной собственности для некоторых членов. не надо в этом искать логику, а то можно быстро до недозволеных речей дойти.
>> какое отношение k&r имеют к текущим стандартам?
> Если ты таки прочитаешь внимательно комментатора, которого несправедливо обосрал, ты поймёшь,
> что он писал про дела минувших дней.а если ты удосужишься почитать его стенания, то увидишь, что он писал напрямую о сегодняшнем дне, и рассказывал, что раньше трава была зеленей. кто ему запрещает взять софт из старых добрых дней и сидеть на нём — не ясно.
стандарт си (как и любой стандарт, где встречаются слова UB, да и вообще любой стандарт, созданный комитетом) — конечно, гуано. но так сложилось, что это последняя инстанция, основополагающий документ. и если этот документ что-то позволяет, то это правильно. если, исходя из документа, некоторые проверки можно удалить — оптимизатор вправе их удалить. особенно если — повторяю в очередной раз — корректная работа оптимизатора гарантирована только для программ, в которых нет UB.
> ни авторы компилятора, ни авторы библиотек не
> обязаны обращать внимание на местечковые обычаи, у них есть документ, которым
> они руководствуются. всё, что в этом документе не описано, они поддерживать
> не должны.Ещё раз тебе пишу - давай вставлять rm -rf $HOME там, где появилось UB.
> потому что общество так договорилось.
В УК в статье про воровство это написано?
> а если ты удосужишься почитать его стенания, то увидишь, что он писал
> напрямую о сегодняшнем дне, и рассказывал, что раньше трава была зеленей.Эволюция культуры - обычное дело. То, что он пишет - вполне правдоподобно, но надо проверять. А возврата к С == ассемблер, быть, разумеется, не может.
> если, исходя из документа, некоторые проверки можно
> удалить — оптимизатор вправе их удалить.Исходя из документа, оптимизатор может ставить rm -rf $HOME в любое место, где есть UB. Но наличие определённой культуры написателям оптимизатора это делать мешает. Поэтому не надо мне рассказывать про то, что написатели оптимизатора должны руководствоваться ИСКЛЮЧИТЕЛЬНО стандартом и желанием оптимизировать.
Я просто желаю, чтобы они выдали предупреждение в том месте, где удаляют проверку. И они, судя по предыдущему подобному косяку, который я видел, это сделают.
> Ещё раз тебе пишу - давай вставлять rm -rf $HOME там, где
> появилось UB.с удовольствием. количество говнокода (и говнокодеров) хотя бы на си после этого сократится в разы.
>> потому что общество так договорилось.
> В УК в статье про воровство это написано?это принцип формирования конституции, знаешь ли.
> Исходя из документа, оптимизатор может ставить rm -rf $HOME в любое место,
> где есть UB. Но наличие определённой культуры написателям оптимизатора это делать
> мешает. Поэтому не надо мне рассказывать про то, что написатели оптимизатора
> должны руководствоваться ИСКЛЮЧИТЕЛЬНО стандартом и желанием оптимизировать.разупарывайся уже, пожалуйста. потому что вот этот процитированный мной абзац — это просто несвязный бред.
> Я просто желаю, чтобы они выдали предупреждение в том месте, где удаляют
> проверку. И они, судя по предыдущему подобному косяку, который я видел,
> это сделают.да вообще на каждое действие по 100500 предупреждений, чего мелочиться-то? совместил оптимизатор две переменные на стеке — предупреждение. убрал «+0» — предупреждение. а уж если посмел переписать выражение в CSE — вообще весь экран должно предупреждениями завалить.
> разупарывайся уже, пожалуйста. потому что вот этот процитированный мной абзац — это
> просто несвязный бред.Это ты, лучше возвращайся из Валинора.
> да вообще на каждое действие по 100500 предупреждений, чего мелочиться-то? совместил оптимизатор
> две переменные на стеке — предупреждение. убрал «+0» — предупреждение.
> а уж если посмел переписать выражение в CSE — вообще весь
> экран должно предупреждениями завалить.На каждое не надо, а на такие приколы ставят.
Именно GCCшники ставят, это же не первый раз замужем. В прошлый раз, который я помню, SPEC поломали. Тоже воплей было, что UB, что можно всё, хоть маму убить. Но кончилось победой разума над идиотизмом - вставили предупреждение.
> Это ты, лучше возвращайся из Валинора.даже если я громче всех захрюкаю, твой текст всё равно останется бредом. я, честно говоря, удивлён, что ты сам этого не видишь: ведь бред он не потому, что «мне не нравятся утверждения», а потому, что они не имеют никакой логической связи, хотя претендуют на то, чтобы иметь.
> На каждое не надо, а на такие приколы ставят.
какие «такие»? соблюдение стандартов? говнокодеры от этого всё равно не начнут учить языки, на которых говнокодят.
> Именно GCCшники ставят, это же не первый раз замужем.
потому что их тоже говнокодеры задалбывают.
> Но кончилось победой разума над идиотизмом
увы, победой идиотов, которые считают, что разумны именно они.
> какие «такие»? соблюдение стандартов? говнокодеры от этого всё равно не начнут
> учить языки, на которых говнокодят.Да, на Цэ написаны тонны говнокода. И что изменится от того, что ты объявишь его неправильным? Ничего.
> потому что их тоже говнокодеры задалбывают.
Если ты поддерживаешь компилятор для языка с 50-ти летней историей, ты подписываешься под ответственностью держать совместимость. Даже с говнокодом. Не хочешь - иди пили компилятор для Rust'а. Или Python'а.
> Да, на Цэ написаны тонны говнокода. И что изменится от того, что
> ты объявишь его неправильным? Ничего.ещё раз: это не причина делать костыли.
>> потому что их тоже говнокодеры задалбывают.
> Если ты поддерживаешь компилятор для языка с 50-ти летней историей, ты подписываешься
> под ответственностью держать совместимость.лолвут? оригинальный сишный код сейчас не соберёт *ни* *один* компилятор. нет, не k&r C, а оригинал.
и да: собирает. и работает. с -O0. ещё раз настырно спрашиваю: в чём проблема прочитать документацию, где говорится о том, какие гарантии даются на оптимизатор?
> ещё раз: это не причина делать костыли.Причина. Та же эпопея со SPEC - либо корректируем SPEC2006 => все предыдущие результаты SPEC2006 на помойку, либо gcc больше не проходит SPEC2006, либо костыль. Папа, что ты хочешь - крокодильчика, удавчика или хомячка?
Тут, где кругом говно, грязь и соответствующий код, почему-то выбирают костыль в gcc. И я даже не понимаю, почему так? В Валиноре, конечно, выбрасывают SPEC.
> Тут, где кругом говно, грязь и соответствующий код, почему-то выбирают костыль в
> gcc.и поэтому там вечно будет говно, грязь и говнокод. по буквам:
в
е
ч
н
ои, само собой, живущие в этом говне всегда будут завидовать «валинору», и от этой зависти требовать, чтобы нормальные разумные существа тоже барахтались в грязи и хрюкали.
> и поэтому там вечно будет говно, грязь и говнокод. по буквам:
> в
> е
> ч
> н
> оБуквы не те. Правильно О П Ж А, а составить нужно слово ВЕЧНОСТЬ. Но ты прав - в реальном мире даже после самой чистой уборки есть место, где лежит грязь. И это, тем не менее, не отменяет необходимости уборки.
Такая, блин, диалектика. Короче, возращайся из Валинора, посмотри вокруг, на реальный мир.
я предлагаю перестать сорить (и за попытку насорить бить канделябром), а ты предлагаешь нанять побольше уборщиков. спасибо, живи в своём мире сам, а мне в моём намного комфортней.
> я предлагаю перестать сорить (и за попытку насорить бить канделябром), а ты
> предлагаешь нанять побольше уборщиков. спасибо, живи в своём мире сам, а
> мне в моём намного комфортней.Ты предлагаешь перестать сорить вообще. На намёки, что это невозможно, и при большом стечении народу будет груда мусора, даже при наличии канделябров, ты обижаешься.
Я предлагаю:
а) сорить по-меньше, включив канделябр.
б) набрать больше уборщиков.
Т.е. стандартный комплексный подход.
P.S.
Разумеется, мы оба живём в моём мире, т.к. он реален.
> Ты предлагаешь перестать сорить вообще.в перспективе — да. начать это с того, что прекратить проявлять терпимость к тем, кто сорит. нет, не «они не виноваты, может, потом поймут», а «подобрал и сожрал, скотина!»
> P.S. Разумеется, мы оба живём в моём мире, т.к. он реален.
конечно, реален — в этом ты прав. а вот в том, что мы там оба — нет. я по необходимости иногда захаживаю к вам (надев предварительно костюм биозащиты, потому как место гиблое), быстро делаю то, за чем зашёл и ухожу.
> в перспективе — да. начать это с того, что прекратить проявлять терпимость
> к тем, кто сорит. нет, не «они не виноваты, может, потом
> поймут», а «подобрал и сожрал, скотина!»Это лишь красивые слова. Ты лучше скажи, что со SPEC'ом делать? Ну расстрелял ты того, кто внёс ошибочный код (если он ещё не помер, конечно), дальше что?
Простая проблема, чётко по теме: gcc последней версии генерирует вылетающий код в одном из тестов SPEC'а, все остальные компиляторы, проходящие SPEC, генерируют работающий. Что делать?
> Что делать?разобраться, где баг и починить его именно там. если по стандарту gcc прав, то баг в тесте, и чинить надо тест.
> разобраться, где баг и починить его именно там. если по стандарту gcc
> прав, то баг в тесте, и чинить надо тест.Ты понимаешь, что все тесты с этим багом станут автоматом невалидны? И их нельзя будет сравнивать с твоим "исправленным"?
> Ты понимаешь, что все тесты с этим багом станут автоматом невалидны?и это правильно. какой смысл в тесте, защищающем ошибку? я-то, наивный, думал, что задача тестов — ошибки как раз выявлять.
> И их нельзя будет сравнивать с твоим "исправленным"?
ну да, мало смысла в том, чтобы проверять правильные тесты ошибочными. я бы даже сказал, не просто мало, а вовсе нет.
> и это правильно. какой смысл в тесте, защищающем ошибку?Он не защищает ошибку, а содержит. Эта ошибка - выход за границы массива при чтении никак себя не проявляет на всех компиляторах, кроме одного.
Если просчитать затраты сил на переделывание всех тестов и вставку костыля окажется, что костыль поставить на несколько порядков дешевле.
> Если просчитать затраты сил на переделывание всех тестов и вставку костыля окажется,
> что костыль поставить на несколько порядков дешевле.и то верно. уборка? да ну, намного дешевле замести мусор под ковёр: там же никто не видит, а, значит, никакого мусора и нет.
> и то верно. уборка? да ну, намного дешевле замести мусор под ковёр:
> там же никто не видит, а, значит, никакого мусора и нет.Это лозунги. Ты сам, внутри себя, чётко осознаёшь правильное решение. И, более того, в подобной ситуации - когда нужно либо вставить костыль, либо переделать сотни тестов, выберешь первое.
Я понимаю, что это для тебя крайне неприятная ломка, мне она тоже много лет назад была неприятна, но таки реальность заставляет. Поэтому прекращай врать как мне, так и себе.
> Это лозунги. Ты сам, внутри себя, чётко осознаёшь правильное решение. И, более
> того…я не менее чётко пишу об этом решении. но, конечно, механизмы компенсации никогда не позволят признать, что кто-то может отказаться жить с говном под ковром. ну, извини, это уже проблема из другой области.
> ты объявишь его неправильным? Ничего.Его или пофиксят, или выкинут. И так и эдак хорошо.
> под ответственностью держать совместимость.
...со стандартами. А не чужим кривым гомнокодом, которого много и весь все-равно не изучишь. Поэтому логично ориентироваться на стандарты, а кто на них забил - ССЗБ. Единственный продолб - отсутствие warning о такой деятельности компилера. Это да, нехорошо.
> пили компилятор для Rust'а. Или Python'а.
Вот пусть гомнокодеры и валят на этом программить, если соблюдать стандарты слишком сложно. Только нефиг потом удивляться что у ЯПов репутация - как у вьюжлвасика, и код такой же. Даже если он идеально отформатирован и без странностей в стандарте - лучше он не становится и работает соответствующе.
> Вот пусть гомнокодеры и валят на этом программить, если соблюдать стандарты слишком
> сложно.вообще-то конкретно сишный — сложно. ты его читал хоть? это из разряда системды: куча крапа, логически который вывести почти невозможно, и потому надо зазубривать.
> ты его читал хоть?Конечно, нет. Тут, по-видимому, вдумчиво читала С-шный стандарт не больше пары человек. А С++-ный, как известно, вообще никто не читал. Однако, и на С, и на С++ пишут.
Так что, про массовые чтения Release Notes, стандартов и т.д. - это прекраснодушные мечтания.
вот в том и беда, что пишут.ну, и в том ещё, что соответствующие стандарты делали комитеты.
> вот в том и беда, что пишут.
> ну, и в том ещё, что соответствующие стандарты делали комитеты.Я и пишу, что ты всё прекрасно понимаешь внутри себя.
> короче говоря, вот ссылка на gcc'шную багзиллу: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61236
> (Status: RESOLVED INVALID)
> суть в том, что в qsort передается переменная-указатель, которая может быть NULL'ом.
> с другой стороны эта функция промаркирована в glibc как такая, которая не
> может принимать NULL на входе (что соответствует стандарту). из этих соображений,
> gcc выводит, что в переменной не может быть NULL и убирает
> проверки.
> обещают в gcc 4.10.0 вывод предупреждения на подобные случаиhttp://grsecurity.net/~spender/exploits/exploit2.txt
всего 4 года прошло.. История повторяется
> обещают в gcc 4.10.0 вывод предупреждения на подобные случаиКруто, а между .9 и .10 что делать? :)
> Круто, а между .9 и .10 что делать? :).8
> .8Ну вот как-то так и получается, если с практической точки зрения смотреть :\. Ибо если они не успели включить патчик с варнингом, но успели включить патчик с столь агрессивной оптимизацией - нарваться на тихую оптимизацию таких вещей не подпертую варнингом было бы не прикольно. Как будто в этом мире мало народа кладет на стандарты.
> Ну вот как-то так и получается, если с практической точки зрения смотреть
> :\.Да. Собственно, я с практической точки зрения и подходил.
> Ибо если они не успели включить патчик с варнингом, но
> успели включить патчик с столь агрессивной оптимизацией - нарваться на тихую
> оптимизацию таких вещей не подпертую варнингом было бы не прикольно. Как
> будто в этом мире мало народа кладет на стандарты.Более того, скажу, что в 96-м году как-то странно не класть на стандарт 99-го. Языку Цэ уже пол века, есть груда унаследованного кода, костылей и т.д. Их нужно учитывать при разработке компилятора.
А если не хочется, то лучше уж запилить новый системный язык, лучше приспособленный под реалии современного дня - вывод типов, GPU, параллельность и т.д.
> Более того, скажу, что в 96-м году как-то странно не класть на стандарт 99-го.Если вы собираете код 96 года, сказав компилеру что надо использовать стандарт 99-го - благородный дон желает чего-то странного, не находите? И не кажется ли вам что единственный кого вы в этом процессе можете обмануть - это вы сами?
> Языку Цэ уже пол века, есть груда унаследованного кода,
> костылей и т.д. Их нужно учитывать при разработке компилятора.А зачем вы на код 96-го года врете компилеру что это C99 и закручиваете оптимизацию? "Если долго портить машину, она сломается".
> А если не хочется, то лучше уж запилить новый системный язык,
Запиливайте, разрешаю.
> GPU, параллельность и т.д.
ИЧСХ, в GCC все это пилят. ИЧСХ, основываясь на си.
> ИЧСХ, в GCC все это пилят. ИЧСХ, основываясь на си.ИЧСХ, получается фигня.
> Запиливайте, разрешаю.Запоздало, т.к. люди над этим давно работают.
> ИЧСХ, в GCC все это пилят. ИЧСХ, основываясь на си.
От такого кол-ва изнасилований Слоник не выдержит и лопнет.
> (что соответствует стандарту).А до 1999-го года ни одной строчки на языке Цэ не написано!!!
> А до 1999-го года ни одной строчки на языке Цэ не написано!!!А для кода древнее 1999 года компилеру может потребоваться указать стандарт, которому он должен следовать.
> А для кода древнее 1999 года компилеру может потребоваться указать стандарт, которому
> он должен следовать.А оно точно уберёт оптимизацию? И вообще, сможет ли эту libc скомпилировать-то?
> А оно точно уберёт оптимизацию? И вообще, сможет ли эту libc скомпилировать-то?если ты используешь glibc, которая следует стандартам 99-го года, с какого испугу ты возмущаешься, что код стандарта 89-го компилируется хреново?
не хочешь править свой код под новый стандарт — бери glibc постарее и страдай.
Про такую штуку, как поддержка совместимости слышал? Про библиотеки, чуть младше тебя и меня, широко используемые в повседневности тоже не слышал?Стандарт специально расширен так, чтобы поддерживать совместимость, а оптимизатор её ломает без объявления войны. Надо было хотя бы предупреждение выкинуть в этом месте.
> Стандарт специально расширен так, чтобы поддерживать совместимостьлолвут? тебе ж выше уже показали, что совместимость поломана.
>> Стандарт специально расширен так, чтобы поддерживать совместимость
> лолвут? тебе ж выше уже показали, что совместимость поломана.Отключаешь эту оптимизацию и видишь невооружённым взглядом, что gcc c этой libc преспокойно компилирует и работает со старой программой, использующей libc. Т.е. 4.8 gcc так и компилировал bind без проблем.
>>> Стандарт специально расширен так, чтобы поддерживать совместимость
>> лолвут? тебе ж выше уже показали, что совместимость поломана.
> Отключаешь эту оптимизацию и видишь невооружённым взглядом, что gcc c этой libc
> преспокойно компилирует и работает со старой программой, использующей libc. Т.е. 4.8
> gcc так и компилировал bind без проблем.молодец. теперь, всё-таки, попробуй сделать остальные шаги. например, почитать всё же документацию к gcc, где пишут, что результат работы оптимизатора на софте с UB — тоже UB. не уверен в том, что в твоей программе нет UB — не включай оптимизатор. всё, проблема решена.
p.s. то, что в 4.9 реализовали дополнительные оптимизации — это хорошо. то, что они ломают софт говнокодеров — тоже хорошо. а вот то, что говнокодеры видят в этом проблему gcc, а не свою — вот это плохо.
> не уверен в том, что в твоей
> программе нет UB — не включай оптимизатор. всё, проблема решена.А ты, умный. Я выше и писал, что при таком подходе -O0 будет у всех. Ибо работающая в 2 раза медленее программа лучше падающей. В любой программе есть ошибки, но ты, конечно, об этом предпочитаешь не думать.
> p.s. то, что в 4.9 реализовали дополнительные оптимизации — это хорошо. то,
> что они ломают софт говнокодеров — тоже хорошо.Предлагаю вообще без предупреждений ставить вызов rm -rf $HOME в том месте, где встретилось UB. А чё, по стандарту можно.
> А ты, умный. Я выше и писал, что при таком подходе -O0
> будет у всех. Ибо работающая в 2 раза медленее программа лучше
> падающей.Лучше все-таки научиться программировать.
> Предлагаю вообще без предупреждений ставить вызов rm -rf $HOME в том месте,
> где встретилось UB. А чё, по стандарту можно.
> Лучше все-таки научиться программировать.И всё, всё, всё переписать. Ты ребёнка за клавиатуру пустил, что ли?
>> Лучше все-таки научиться программировать.
> И всё, всё, всё переписать. Ты ребёнка за клавиатуру пустил, что ли?Можно и не переписывать, а просто уважать стандарты и хотя бы иногда пользоваться средствами статического анализа.
Хотя это все не для бравых С-программистов, конечно.
> Можно и не переписывать, а просто уважать стандартыМолодец. Это ты пишешь про новый софт, а я тебе про старый, работающий десятилетиями. Типа WindowMaker'а.
>> Можно и не переписывать, а просто уважать стандарты
> Молодец. Это ты пишешь про новый софт, а я тебе про старый,
> работающий десятилетиями. Типа WindowMaker'а.Старый софт мне тоже поддерживать приходилось. Ничего, практика показывает, что соблюдение стандартов и постепенное вычитывание и исправление кода вокруг того, что ты модифицируешь, помогает.
>> Можно и не переписывать, а просто уважать стандарты
> Молодец. Это ты пишешь про новый софт, а я тебе про старый,
> работающий десятилетиями. Типа WindowMaker'а.прикинь, старые исходники тоже можно чинить. за это молния с неба не ударит. то, что некий баг в софте жил десятилетиями и по счастливой случайности софт с багом работал, ещё не значит, что теперь этот баг освящён временем, и править его — ересь с богохульством.
> прикинь, старые исходники тоже можно чинить.Прикинь, если получить предупреждение в subj'евом месте, чинить будет на порядки быстрее и дешевле.
>> прикинь, старые исходники тоже можно чинить.
> Прикинь, если получить предупреждение в subj'евом месте, чинить будет на порядки быстрее
> и дешевле.прикинь, для этого придумали статические анализаторы. и продолжают их совершенствовать. а взваливать задачу анализа на компилятор — это без нужды компилятор усложнять и увеличивать время сборки.
> прикинь, для этого придумали статические анализаторы. и продолжают их совершенствовать.
> а взваливать задачу анализа на компилятор — это без нужды компилятор
> усложнять и увеличивать время сборки.Прикинь, компилятор всё равно обрабатывает этот случай.
> Прикинь, компилятор всё равно обрабатывает этот случай.прикинь, если снять с компилятора задачу диагностики, то можно сильно упростить код обработки и внутреннее представление программы. например, потому, что не надо будет пытаться превратить некое смещение в IR назад в человекочитаемый формат.
> прикинь, если снять с компилятора задачу диагностики, то можно сильно упростить код
> обработки и внутреннее представление программы.Прикинь, движение ИТ всю жизнь идёт в обратную сторону - компьютер должен работать, а человек думать. И работа корректором постепенно перекладывается на сторону компьютера.
> Прикинь, движение ИТ всю жизнь идёт в обратную сторону - компьютер должен
> работать, а человек думать. И работа корректором постепенно перекладывается на сторону
> компьютера.прикинь, если ты разупорешься и попробуешь запоминать хотя бы несколько сообщений оппонентов, то с удивлением увидишь, что я не предлагаю упразднить диагностику per se.
> то с удивлением увидишь, что я не предлагаю упразднить диагностику per
> se.Прикинь, если ты сам вернёшься из Валинора, ты узнаешь, что здесь стат. анализатора, комплиментарного GCC нет. Поэтому здесь и сейчас предупреждение надо ставить в GCC.
прикинь, а когда-то считали, что альтернативы рабскому труду нет, поэтому нужно больше рабов.
> прикинь, а когда-то считали, что альтернативы рабскому труду нет, поэтому нужно больше
> рабов.Прикинь, если бы мы тогда жили, мы бы так и считали. Ибо, чтобы нужно было меньше рабов, должны пройти определённые изменения, НТР всякое.
прикинь, если ничего не менять — ничего и не изменится. я предлагаю прекратить нанимать новых рабов и начать менять мир к лучшему, а ты — продолжить нанимать рабов и оставить задачу по изменению мира кому-то другому. спасибо, надеюсь, я никогда не «повзрослею» до уровня, когда тоже буду так думать.
> спасибо, надеюсь, я никогда не «повзрослею» до уровня, когда
> тоже буду так думать.Повзрослеешь. Более того, ты наверняка уже повзрослел. Нужно просто перестать врать самому себе и нам.
> Повзрослеешь. Более того, ты наверняка уже повзрослел. Нужно просто перестать врать самому
> себе и нам.да-да-да-да. «перестань уже выпендриваться! ишь, моется он каждый день! перестань уже врать, мы же знаем, что на самом деле всё не так!»
> да-да-да-да. «перестань уже выпендриваться! ишь, моется он каждый день! перестань
> уже врать, мы же знаем, что на самом деле всё не
> так!»Я не сомневаюсь, что ты, лично, моешься каждый день. И Сшный стандарт читаешь, и Release Notes. А 99%, пишущих на C этого не делает.
> А 99%, пишущих на C этого не делает.это их личные проблемы. не вижу, отчего я должен в честь сего начать хрюкать.
>> да-да-да-да. «перестань уже выпендриваться! ишь, моется он каждый день! перестань
>> уже врать, мы же знаем, что на самом деле всё не
>> так!»
> Я не сомневаюсь, что ты, лично, моешься каждый день. И Сшный стандарт
> читаешь, и Release Notes. А 99%, пишущих на C этого не
> делает.Не моются?
> Не моются?ещё хуже: настаивают, чтобы и другие не мылись. потому что мыться — ненормально: если бы бох хотел видеть людей чистыми, он бы создал их непачкающимися.
Совершенно верно. При этом ты, почему-то, настаиваешь на том, что давайте прямо тут бактериологические эксперименты ставить. А если кто из этих чумазых обывателей не простерилизовался и умер от дизентерии, я не виноват!
я предлагаю перестать считать, что дизентерия — это божья кара, что спасение лежит в усердных молитвах и плакатах «не греши», и начать, наконец, соблюдать санитарные нормы. а тех, кто их соблюдать не желает, изолировать в большой яме и забыть о них. следить только, чтобы не вылезли.
> а тех, кто их соблюдать не желает, изолировать в большой яме и забыть о них. следить только, чтобы не вылезли.Так это же почти все. Ну кроме тебя и ещё пары человек.
> Так это же почти все.ну и что? большинству говнокода лучше оставаться ненаписаным.
> ну и что? большинству говнокода лучше оставаться ненаписаным.Фа-арш невозможно провернуть наза-ад.
само собой. грязные руки невозможно вымыть, поэтому нет смысла даже начинать.
> само собой. грязные руки невозможно вымыть, поэтому нет смысла даже начинать.Исключительно постепенным комплексом мер.
"Конечно, обыватели должны быть всегда готовы к перенесению всякого рода мероприятий, но при сем они не лишены некоторого права на их постепенность. В крайнем случае, они могут даже требовать, чтобы с ними первоначально распорядились, и только потом уже палили. Ибо, как я однажды сказал, ежели градоначальник будет палить без расчета, то со временем ему даже не с кем будет распорядиться..."
А ты хочешь сразу палить.
> А ты хочешь сразу палить.и желательно — вместе с родственниками. если непонятно, почему — то и пояснять бессмысленно.
> и желательно — вместе с родственниками. если непонятно, почему — то и
> пояснять бессмысленно.Да понятно почему - это инстинктивное желание. Но на уровне градоначальника нужно всё-таки свои инстинкты слегка умерять. Иначе останешься один с письмоводителем.
> Да понятно почемукак я и сказал — пояснять бессмысленно. конечно, ничего ты не понял, но уверен, что понял.
>> не уверен в том, что в твоей
>> программе нет UB — не включай оптимизатор. всё, проблема решена.
> А ты, умный.таки да.
> Я выше и писал, что при таком подходе -O0 будет у всех.
отучаемся говорить за всю сеть. у говнокодеров — да. люди же, которые возьмут на себя труд изучить язык, на котором пытаются писать, вполне в состоянии делать код без UB (само собой, не обязательно сразу — но для того и существует тестирование с отладкой). вторые называются «программисты», а первые — «говнокодеры».
> Ибо работающая в 2 раза медленее программа лучше падающей.
а ещё лучше — и работающая быстро, и не падающая. но это же не говнокод писать, это надо где-то добыть рабочий мозг и поправить ошибки в своей программе. намного проще не мучаться и просто сказать, что компилятор, сволочь такая, испортил своими оптимизациями Великолепный Код.
> В любой программе есть ошибки, но ты, конечно, об этом
> предпочитаешь не думать.ты прав: я об этом не думаю, я просто их чиню. если бы я вместо починки сидел и философствовал о том, что в любой программе есть ошибки, то тоже ругался бы на мерзкие компиляторы, наверное.
>> p.s. то, что в 4.9 реализовали дополнительные оптимизации — это хорошо. то,
>> что они ломают софт говнокодеров — тоже хорошо.
> Предлагаю вообще без предупреждений ставить вызов rm -rf $HOME в том месте,
> где встретилось UB. А чё, по стандарту можно.отличная идея, кстати. правда, боюсь, что такой патч не примут. ну, не говоря уже о том, что его и написать невозможно, потому что если бы можно было отлавливать все UB на стадии компиляции, их бы и отлавливали.
> отличная идея, кстати. правда, боюсь, что такой патч не примут. ну, не
> говоря уже о том, что его и написать невозможно, потому что
> если бы можно было отлавливать все UB на стадии компиляции, их
> бы и отлавливали.Ну, на самом деле можно, по крайней мере, конкретно такой класс ошибок. Правда, время компиляции это увеличит в разы.
> Ну, на самом деле можно, по крайней мере, конкретно такой класс ошибок.
> Правда, время компиляции это увеличит в разы.вот поэтому инструменты статического анализа от компиляторов постепенно отрывают. ну, то есть, они и раньше не были особо приклеены, но народ требует всё больше и больше ворнингов. правильное направление развития — как по мне — это lint отдельно, компилятор отдельно. кому хочется — запускает сначала lint, потом компилятор. кому не хочется — сразу компилятор.
> по мне — это lint отдельно, компилятор отдельно. кому хочется —
> запускает сначала lint, потом компилятор. кому не хочется — сразу компилятор.Угу. Самая большая проблема, почему нельзя стат. анализатор встроить в компилятор - это большое кол-во ложных положительных срабатываний. Компиляция в идеале должна проходить без предупреждений (кстати, часто невозможно, если компиляторов несколько).
> Угу. Самая большая проблема, почему нельзя стат. анализатор встроить в компилятор -
> это большое кол-во ложных положительных срабатываний.Не соглашусь, это все-таки время работы. Статический анализатор спокойно можно по крону раз в сутки прогонять, а не при каждой компиляции, которых за рабочий день может быть сотня-две.
> Компиляция в идеале должна проходить
> без предупреждений (кстати, часто невозможно, если компиляторов несколько).С чего бы это невозможно?
> С чего бы это невозможно?а как раз из-за анализаторов. один компилятор ругается на то, что переменная, возможно, неиничиализирована. затыкаешь его при помощи int x = x — другой начинает ругаться на то, что лишнее бессмысленное присваивание появилось. в итоге пишешь дурацкое int x = 0 и добавляешь в комментарии: «я знаю, что это не нужно, но иначе идиот-компилятор XYZ не затыкается.»
> Не соглашусь, это все-таки время работы. Статический анализатор спокойно можно по крону
> раз в сутки прогонять, а не при каждой компиляции, которых за
> рабочий день может быть сотня-две.У PVS-овцев реализована инкременталка.
> С чего бы это невозможно?
С того, что предупреждения противоречат друг другу. Скажем, один компилятор ругается на пустой default: в switch'е, а второй - на отсутствие default: (это то, что я помню, а есть и другие предупреждения). Можно, конечно, отключить часть предупреждений, но лучше этого не делать.
> У PVS-овцев реализована инкременталка.Про свои впечатления от PVS я уже тоже писал.
> С того, что предупреждения противоречат друг другу. Скажем, один компилятор ругается на
> пустой default: в switch'еЭм, это какой так ругается?
> а второй - на отсутствие default: (это
> то, что я помню, а есть и другие предупреждения).Не встречал ни одного, который бы на это не ругался.
> Про свои впечатления от PVS я уже тоже писал.Я, естественно, про них помню. Но, я тебе, как умному собеседнику, намекаю, что и другие также могут сделать.
> Эм, это какой так ругается?
У меня была связка ICC, MSVC, SUN Pro, gcc и clang. Вот один из первых 4-х. Наверно, SUN Pro.
> С того, что предупреждения противоречат друг другу. Скажем, один компилятор ругается на
> пустой default: в switch'е, а второй - на отсутствие default: (это
> то, что я помню, а есть и другие предупреждения).На отсутствие default ругается только в том случае, если для переключалки используешь enum и не все варианты из этого enum заюзал в switch'е. Т.е. в данном случае сделал что-то не совсем корректное и лучше пересмотреть код и исправить логику.
> На отсутствие default ругается только в том случае, если для переключалки используешь
> enum и не все варианты из этого enum заюзал в switch'е.
> Т.е. в данном случае сделал что-то не совсем корректное и лучше
> пересмотреть код и исправить логику.Не совсем, тут все довольно тупо, к сожалению. Даже если есть какой-нибудь enum class Foo { Foo1, Foo2, Foo3 };, где другое значение не получить без UB, и есть код вроде
T DoFoo (Foo foo)
{
if (foo != Foo::Foo1 && foo != Foo::Foo2)
return {};switch (foo)
{
case Foo::Foo1:
case Foo::Foo2:
return {};
}
}то компилятор все равно ругнется, мол, не все пути выполнения возвращают что-либо.
Ещё проще есть - return прямо после switch c default: один компилятор ругается на unreachable code, другой - на function without return.
> На отсутствие default ругается только в том случае, если для переключалки используешь
> enum и не все варианты из этого enum заюзал в switch'е.
> Т.е. в данном случае сделал что-то не совсем корректное и лучше
> пересмотреть код и исправить логику.Пересмотрел 2 раза, логика корректна. Мне теперь повеситься из-за какого-то вшивого предупреждения?
>> На отсутствие default ругается только в том случае, если для переключалки используешь
>> enum и не все варианты из этого enum заюзал в switch'е.
>> Т.е. в данном случае сделал что-то не совсем корректное и лучше
>> пересмотреть код и исправить логику.
> Пересмотрел 2 раза, логика корректна. Мне теперь повеситься из-за какого-то вшивого предупреждения?Зачем вешаться? Оставайся - одним говнокодером больше, одним меньше - какая разница?
> Зачем вешаться? Оставайся - одним говнокодером больше, одним меньше - какая разница?Такую чушь лучше писать из-под анонимуса. Тебе не придётся потом ник удалять.
> Зачем вешаться? Оставайся - одним гoвнокодером больше, одним меньше - какая разница?Лишний пример того что академики - хреновые программисты.
>> На отсутствие default ругается только в том случае, если для переключалки используешь
>> enum и не все варианты из этого enum заюзал в switch'е.
>> Т.е. в данном случае сделал что-то не совсем корректное и лучше
>> пересмотреть код и исправить логику.
> Пересмотрел 2 раза, логика корректна. Мне теперь повеситься из-за какого-то вшивого предупреждения?Написать пустые case'ы для необработанных случаев с одним-единственным break. Так и человеку будет понятно, что их не забыли, и компилятор угомонится, и после добавления новых элементов в енам компилятор на это место ругнется.
> Написать пустые case'ы для необработанных случаев с одним-единственным break. Так и человеку
> будет понятно, что их не забыли, и компилятор угомонится, и после
> добавления новых элементов в енам компилятор на это место ругнется.enum с десятком параметров, нужно сделать выделенный случай для 2-х. Если я вставлю оставшиеся 8-мь, будет ужасно некрасиво.
самая большая проблема — это то, что компилировать оно будет 100500 длинных единиц времени, и требовать для этого 100500 больших единиц памяти. причём абсолютно для всего кода, даже для того, который уже был проверен. конечно, можно не указывать -W для тех файлов, где это уже не надо, но специфика сегодняшних «больших» компиляторов такова, что они всё равно пытаются при этом проводить некоторый анализ. хотя неуказание -W должно обозначать «я гарантирую, что в этом коде нет UB и отдаю себе отчёт во всех последствиях этой гарантии».
> отличная идея, кстати. правда, боюсь, что такой патч не примут.Если ты пропихнёшь такой патч, тебе сильно подрихтуют физиономию неформализуемыми методами. Вещь довольно очевидная, поэтому возращайся из Валинора.
>> отличная идея, кстати. правда, боюсь, что такой патч не примут.
> Если ты пропихнёшь такой патч, тебе сильно подрихтуют физиономию неформализуемыми методами.кто же спорит, идиотов-говнокодеров всегда было много. массой задавят. как Дреппера с memcpy().
> кто же спорит, идиотов-говнокодеров всегда было много. массой задавят. как Дреппера с
> memcpy().Да нет, ты просто всё ещё в Валиноре, где всё строго и перпендикулярно.
> Да нет, ты просто всё ещё в Валиноре, где всё строго и
> перпендикулярно.конечно, вместо этого мне надо всё забыть и весело нырнуть в говно, а потом похрюкать.
> В этом треде ты, к сожалению, конкретно обосрался. так что нечего на
> ботов сворачивать:)А-аа, так ты ставишь минусы вручную? От лох-то. :-)
> отучаемся говорить за всю сеть. у говнокодеров — да. люди же, которые
> возьмут на себя труд изучить язык, на котором пытаются писать, вполне
> в состоянии делать код без UB (само собой, не обязательно сразу
> — но для того и существует тестирование с отладкой).Это у вас в Валиноре можно сделать Сшную программу на мегабайт текстов без UB?
> Это у вас в Валиноре можно сделать Сшную программу на мегабайт текстов
> без UB?да даже на десятки мегабайт. но «обычным людям» это будет сложно, конечно: их сначала хотя бы умываться регулярно надо научить.
> да даже на десятки мегабайт.Только не на языке Цэ.
>> да даже на десятки мегабайт.
> Только не на языке Цэ.ну, хреново быть тобой, что я ещё сказать могу…
> ну, хреново быть тобой, что я ещё сказать могу…Многие знания, многие печали. Но нет, не настолько хреново, чтобы уходить в Валинор.
>> не уверен в том, что в твоей
>> программе нет UB — не включай оптимизатор. всё, проблема решена.
> А ты, умный. Я выше и писал, что при таком подходе -O0
> будет у всех. Ибо работающая в 2 раза медленее программа лучше
> падающей. В любой программе есть ошибки, но ты, конечно, об этом
> предпочитаешь не думать.В "2 раза"? Вы недооцениваете силу "-O2". И ещё не стоит забывать, что кроме обычных корпоративных сервисов, ещё бывают HPC-задачи. Там вы тоже считаете разумным "-O0"?
> ещё бывают HPC-задачи. Там вы тоже считаете разумным "-O0"?что лучше: офигенно быстрая программа, которая считает полную фигню, или медленная, но которая считает правильно? от второй рано или поздно всё-таки можно получить полезный результат, от первой — никогда.
>> ещё бывают HPC-задачи. Там вы тоже считаете разумным "-O0"?
> что лучше: офигенно быстрая программа, которая считает полную фигню, или медленная, но
> которая считает правильно? от второй рано или поздно всё-таки можно получить
> полезный результат, от первой — никогда.Скапитаню -- нужно писать быстрые программы, дающие верный результат. Другими словами, обе программы требуют исправления. Это просто два говнокода. Я сталкивался с ошибками оптимизатора в gcc, которые приводили некоторые программы в неработоспособность, но я не ленился обходить данные проблемы. А уж тем более, если программа не работает в "-O2" из-за нарушения стандартов, то это уже вполне однозначно говнокод.
К тому же многие HPC-задачи масштабируются сильно нелинейно (намного слабее). А следовательно не всегда есть возможность скомпенсировать недостаточную производительность избыточностью вычислительных ресурсов (даже при наличии доступа к большим вычислительным системам). В результате на "-O0" может так случиться, что задачу придётся считать с недостаточной точностью, либо получать результат, когда уже будет неактуально.
Вообще, я считаю, что программу нужно разрабатывать в наиболее суровых условиях и устранять все найденные неполадки (при наличии такой возможности). В частности "-O2" даёт возможность увидеть дополнительные проблемы и улучшить качество кода. Я уж не говорю про то, что он даёт весьма существенное ускорение на большинстве задач.
ты же не спрашивал, что с софтом надо делать, ты спросил, какая лучше. лучше — медленная, но работающая верно.а то, что говнокод надо уничтожать — я же согласен.
> ты же не спрашивал, что с софтом надо делать, ты спросил, какая
> лучше. лучше — медленная, но работающая верно.Хех, нет, я такого не спрашивал. Я извиняюсь, если я какой-то вопрос некорректно сформулировал, но я нигде такого не подразумевал. Я лишь спрашивал является ли разумным использование "-O0" из соображений, что так будет меньше вероятность ошибки (что, как я понял, является мнением вашего оппонента в дискуссии чуть выше), вместо тупого исправления ошибок. Другими словами, я лишь пытался пояснить, что не будет у всех "-O0", так как другие люди (в отличие от некоторых) исправляют свой код.
> Я выше и писал, что при таком подходе -O0 будет у всех.
Прошу прощения, если что-то неправильно понял или сформулировал в своём ответе.
>> ты же не спрашивал, что с софтом надо делать, ты спросил, какая
>> лучше. лучше — медленная, но работающая верно.
> Хех, нет, я такого не спрашивал.ну, значит я тебя так понял. пардон. недопонимания случаются.
в описаном акцепте, конечно, рекомендация собирать с -O0 — это, собственно, почти стопроцентной вероятности индикатор говнокода. исключение — это если в README перечислены багрепорты авторам компилятора. ;-)
> Скапитаню -- нужно писать быстрые программы, дающие верный результат.Да, вы абсолютно правы. Нужно. А ещё нужно учиться на одни пятёрки, слушаться старших, ни пить, ни курить, ни болеть.
Но, даже если я всё это делаю, остаются миллионы, которые ведут себя несколько не так. И весь спор с arisu в том, что я учитываю наличие этих миллионов, а он от них демонстративно отворачивается с возгласами "расстрелять усих".
>> Скапитаню -- нужно писать быстрые программы, дающие верный результат.
> Да, вы абсолютно правы. Нужно. А ещё нужно учиться на одни пятёрки,
> слушаться старших, ни пить, ни курить, ни болеть.Если не будете учиться на пятёрки, слушаться других, а также будете пить, курить и болет, то это будут лично ваши проблемы.
А если будете писать говнокод, то это уже создаст проблемы каждому, кто будет сталкиваться с данным кодом.
Уж лучше учиться на 3-ки и 4-ки, но писать нормальный диплом, диссертацию и код, чем учиться на пятёрки и делать говно-диплом и говнокод (как оно зачастую и бывает IRL, как ни странно).
> Но, даже если я всё это делаю, остаются миллионы, которые ведут себя
> несколько не так.Если есть миллионы говнокодеров, это ещё не повод самому становиться говнокодером. Пусть живут своей жизнью, пишут свои нахрен не нужные программы и радуются. Главное, что в нормальной прослойке инженеров быть говнокодером не считалось нормой.
> И весь спор с arisu в том, что
> я учитываю наличие этих миллионовЗачем? Если человек не способен написать приемлемый код, то не нужно учитывать его мнение относительно программирования и компиляторов.
>, а он от них демонстративно отворачивается
> с возгласами "расстрелять усих".Не надо расстреливать, нужно просто игнорировать.
> Если не будете учиться на пятёрки, слушаться других, а также будете пить, курить и болет, то это будут лично ваши проблемы.Разумеется, нет. Скажем, есть ли у вас братья-сёстры?
> Зачем? Если человек не способен написать приемлемый код, то не нужно учитывать его мнение относительно программирования и компиляторов.
Возьмём Л. Поттеринга. Он пишет приемлимый код? Нужно учитывать его действия по пропихиванию systemd везде и всюду?
>> Если не будете учиться на пятёрки, слушаться других, а также будете пить, курить и болет, то это будут лично ваши проблемы.
> Разумеется, нет. Скажем, есть ли у вас братья-сёстры?
>> Зачем? Если человек не способен написать приемлемый код, то не нужно учитывать его мнение относительно программирования и компиляторов.
> Возьмём Л. Поттеринга. Он пишет приемлимый код? Нужно учитывать его действия по
> пропихиванию systemd везде и всюду?Не знаю какой код пишет лично он (не сверял какая строка кем именно написана), знаю лишь что systemd - отвратительный software bundle, который решает псевдопроблемы путём многочисленных lock-in-ов и зависимостей. Знаю, что Торвальдс произносит "PulseAudio" как "Pu.psh.sAddia...u..psh", притом не зря (судя по моему личному опыту работы с ним). И ещё немало таких вещей знаю. Но спорить на эту тему не собираюсь, ибо эта тема меня уже слишком надоела.
Но вы к чему эти вопросы-то задали? Что хотели дальше объяснить?
> Не знаю какой код пишет лично он (не сверял какая строка кем
> именно написана), знаю лишь что systemd - отвратительный software bundle, который
> решает псевдопроблемы путём многочисленных lock-in-ов и зависимостей....
> Но вы к чему эти вопросы-то задачи? Что хотели дальше объяснить?
К тому, что несмотря на то, что этот кадр плодит лютое говно, нам необходимо его учитывать в своих планах. Учитывать - это не значит поддерживать. А игнорировать его, увы, себе дороже.
>> Не знаю какой код пишет лично он (не сверял какая строка кем
>> именно написана), знаю лишь что systemd - отвратительный software bundle, который
>> решает псевдопроблемы путём многочисленных lock-in-ов и зависимостей.
> ...
>> Но вы к чему эти вопросы-то задачи? Что хотели дальше объяснить?
> К тому, что несмотря на то, что этот кадр плодит лютое говно,
> нам необходимо его учитывать в своих планах. Учитывать - это не
> значит поддерживать. А игнорировать его, увы, себе дороже.Пфф. Лично я некоторое время немного помогал OpenRC в этом году. И следующей зимой планирую снова помогать. И я планирую пользоваться именно им как и в Debian, так и в Gentoo. Мне плевать на systemd и прочее. Конечно неприятно, что они развиваются и переманивают на себя свободное сообщество, но по большому счёту всё это несущественно. Лично мне вполне хватает размера комьюнити, которое не поддержало systemd.
> мне вполне хватает размера комьюнити, которое не поддержало systemd.Мне тоже. И это прекрасно, но ряд программ, увы, монополисты.
>> мне вполне хватает размера комьюнити, которое не поддержало systemd.
> Мне тоже. И это прекрасно, но ряд программ, увы, монополисты.Мне нравится аналогия arisu по поводу рабского труда. Если люди вокруг идиоты и поддерживают идиотизм, из этого ещё не следует, что и мы с вами должны его поддерживать.
Мы должны стремиться к чему-то более разумному и ставить такие установки, которые приводят нас к этому разумному, а не к тому дебилизму.
В общем, я призываю не прогибаться под идиотизм. И если кто-то плодить говнокод, это ещё не значит, что под него нужно подстраиваться.
> В "2 раза"? Вы недооцениваете силу "-O2". И ещё не стоит забывать, что кроме обычных корпоративных сервисов, ещё бывают HPC-задачи. Там вы тоже считаете разумным "-O0"?Если есть выбор в том, что чужой некритичный код работает при -O0 и не работает при -O2 (при этом разбираться неделю), то, очевидно, нужно взять -O0 и отписать письмо об ошибке разработчику (если он, конечно, ещё есть). Это типичная ситуация для сборщика пакета для Linux дистрибутива. Отсюда и пляшем.
В других ситуациях - когда код свой или критичный, нужно разбираться и искать ошибку. В общем, по обстоятельствам, без идиотизма.
>> В "2 раза"? Вы недооцениваете силу "-O2". И ещё не стоит забывать, что кроме обычных корпоративных сервисов, ещё бывают HPC-задачи. Там вы тоже считаете разумным "-O0"?
> Если есть выбор в том, что чужой некритичный код работает при -O0
> и не работает при -O2 (при этом разбираться неделю), то, очевидно,
> нужно взять -O0 и отписать письмо об ошибке разработчику (если он,
> конечно, ещё есть). Это типичная ситуация для сборщика пакета для Linux
> дистрибутива. Отсюда и пляшем.
> В других ситуациях - когда код свой или критичный, нужно разбираться и
> искать ошибку. В общем, по обстоятельствам, без идиотизма.Да, но добавлю, что IMHO создание UB в коде (выходя за стандарт) -- это ССЗБ. И виноват в последствиях будет тот, кто допустил UB, а не тот, кто поменял поведение компилятора, если он работает в рамках стандарта.
Единственное мнение о поведении которое нужно учитывать -- это только стандарт. Если компилятор ему соответствует, то все вопросы только к автору программы.
Честно сказать вообще не очень понимаю о чём тут ваш спор. Ведь всё так очевидно. =\
> Да, но добавлю, что IMHO создание UB в коде (выходя за стандарт)
> -- это ССЗБ. И виноват в последствиях будет тот, кто допустил
> UB, а не тот, кто поменял поведение компилятора, если он работает
> в рамках стандарта.Это вы говорите про непосредственного виновника. Непосредственный виновник - это тот, кто создал UB. Точно также, как непосредственный виновник ДТП - тот, кто первым нарушил ПДД.
Тем не менее, на дороге, как правило, авария происходит из-за нескольких ошибок разных людей. И, как правило, если все выполняют известное правило ДДД, аварии не происходит. Поэтому, разумно кроме непосредственного виновника инцидента выделять и косвенных виновников. И, таки, оптимизаторы gcc становятся косвенными виновниками падения bind'а.
Ещё простой вопрос - у нас есть debug и release сборки. Какая из них должна быть более "хрупкой"? Легче падающей при прочих равных?
>[оверквотинг удален]
>> -- это ССЗБ. И виноват в последствиях будет тот, кто допустил
>> UB, а не тот, кто поменял поведение компилятора, если он работает
>> в рамках стандарта.
> Это вы говорите про непосредственного виновника. Непосредственный виновник - это тот, кто
> создал UB. Точно также, как непосредственный виновник ДТП - тот, кто
> первым нарушил ПДД.
> Тем не менее, на дороге, как правило, авария происходит из-за нескольких ошибок
> разных людей. И, как правило, если все выполняют известное правило ДДД,
> аварии не происходит. Поэтому, разумно кроме непосредственного виновника инцидента выделять
> и косвенных виновников.Прошу без автомобильных аналогий, ибо я лишь пешеход (до работы пешком идти 15 минут). Однако насколько я понимаю, следование ПДД всеми участниками движения не гарантирует невозникновение аварийных ситуаций (где уже кто-то будет тупо вынужден в кого-то врезаться и стать в результате нарушителем), в то время как следование стандарту языка гарантирует правильную работу кода (при корректном компиляторе). Поправьте, если не прав, ибо я не знаю ПДД. К тому же, когда ты пишешь код и ты видишь UB, то у тебя есть возможность его исправить, а когда случилось ДТП -- у тебя уже нет возможности его исправить. А если же ты не видишь UB (а оно есть), значит ты, грубо говоря, хреновый программист и виноват сам.
> И, таки, оптимизаторы gcc становятся косвенными виновниками падения
> bind'а.Даватйе ещё эффект бабочки вспомним. В принципе, можно сказать что виноват вообще Ленин. Если бы не он, тогда какой-нибудь талантливый инженер (уже при Сталинском режиме) мог переехать куда-нибудь в США и в будущем помочь развитию bind-а, что помогло бы избежать именно этой проблемы с UB. Но Ленин, как и разработчики gcc, лишь выполнял свою задачу. Делать его ответственным за баг в bind-е -- это по меньшей мере нелепо.
Разработчики gcc не должны думать о таких вот эффектах. Задача gcc - корректно транслировать код. И он это делает. Не вижу что тут обсуждать. Не вижу никакой вины со стороны разработчиков gcc.
Более того, всем ведь известно, что нельзя использовать критические вещи версии "x.y.0". Если кто-то компилировал bind с помощью gcc 4.9.0, то он ССЗБ. Если же нет, то и проблемы нет. Сейчас о проблеме gcc4.9-vs-bind уже известно и пока не исправили bind нужно его тупо компилить с помощью gcc4.8.
> Ещё простой вопрос - у нас есть debug и release сборки. Какая
> из них должна быть более "хрупкой"? Легче падающей при прочих равных?Что такое "хрупкая" сборка? Естественно ветка вводимая в production должна работать надёжно. А обычно это release-сборки, а следовательно...
P.S.: Кстати говоря извиняюсь, работаю за ноутом, где не настроен Compose-key, в результате длинный дефис делаю через два минуса и т.п.
> Прошу без автомобильных аналогий, ибо я лишь пешеход (до работы пешком идти
> 15 минут).Ок. Тогда аналогия простая - вы, переходя дорогу на зелёный свет, можете смотреть в небо, но лучше глядеть по сторонам.
> Однако насколько я понимаю, следование ПДД всеми участниками движения
> не гарантирует невозникновение аварийных ситуаций (где уже кто-то будет тупо вынужден
> в кого-то врезаться и стать в результате нарушителем),Почему? ПДД пишутся для того, чтобы при полном соблюдении ПДД и исправности транспорта аварий не было в принципе.
> Поправьте, если не прав, ибо я не знаю ПДД. К тому
> же, когда ты пишешь код и ты видишь UB, то у
> тебя есть возможность его исправить, а когда случилось ДТП -- у
> тебя уже нет возможности его исправить.Это, если код пишешь ТЫ. А если это огромная, дико полезная программа с полувековой историей (типа Maxima)?
Ещё пронзительнее пример - ScanKromsator, который некий Bolega начал писать году в 1996-м. Программа дико полезна - ей обработана подавляющая часть .djvu файлов со сканами отечественной технической литературы. Но это именно говнокод, где его автор - непонятно, где исходники - тоже. Глюков море, но переписывание займёт лет 10, т.к. внутре SK хорошие алгоритмы + эвристики.
> Но Ленин, как и разработчики gcc лишь выполнял свою задачу, они
> не должны думать о таких побочных эффектах.Ленин - нет, а gccшники - да.
Буквально год назад был пример с поломкой SPEC. Тоже ошибка в тесте, тоже ломает оптимизация gcc. Но при выборе "удавчик, крокодильчик или хомячок": исправление SPEC => все предыдущие результаты в унитаз, забить => gcc больше не проходит SPEC, вставить костыль; почему-то выбирают 3-й вариант.
> Что такое "хрупкая" сборка? Естественно ветка вводимая в production должна работать надёжно.
> А обычно это release-сборки, следовательно...Вы правильно всё поняли. Следовательно, debug мы компилируем с -O2, а release - с -O0? ;-)
>> Прошу без автомобильных аналогий, ибо я лишь пешеход (до работы пешком идти
>> 15 минут).
> Ок. Тогда аналогия простая - вы, переходя дорогу на зелёный свет, можете
> смотреть в небо, но лучше глядеть по сторонам.И? Поясните для тупого, как конкретно эта аналогия связана с данным диалогом? :)
>> Однако насколько я понимаю, следование ПДД всеми участниками движения
>> не гарантирует невозникновение аварийных ситуаций (где уже кто-то будет тупо вынужден
>> в кого-то врезаться и стать в результате нарушителем),
> Почему? ПДД пишутся для того, чтобы при полном соблюдении ПДД и исправности
> транспорта аварий не было в принципе.Мне, например, рассказывали про ситуации с маленькими автомобилями, которые не видно из больших автомобилей. Вроде как в рамках соблюдения ПДД образовывалась авария. Но я, как я уже сказал, некомпетентен в данном вопросе, поэтому спорить не буду.
>> Поправьте, если не прав, ибо я не знаю ПДД. К тому
>> же, когда ты пишешь код и ты видишь UB, то у
>> тебя есть возможность его исправить, а когда случилось ДТП -- у
>> тебя уже нет возможности его исправить.
> Это, если код пишешь ТЫ. А если это огромная, дико полезная программа
> с полувековой историей (типа Maxima)?В чём разница? Замените "ты" на "авторы Maxima".
> Ещё пронзительнее пример - ScanKromsator, который некий Bolega начал писать году в
> 1996-м. Программа дико полезна - ей обработана подавляющая часть .djvu файлов
> со сканами отечественной технической литературы. Но это именно говнокод, где его
> автор - непонятно, где исходники - тоже. Глюков море, но переписывание
> займёт лет 10, т.к. внутре SK хорошие алгоритмы + эвристики.Не пример для меня. Не пользовался такой программой. Однако, если код говно, то он -- говнокод. И виноваты в этом его авторы, а не авторы компиляторов. Это вообще не задача компиляторов подстраиваться под такие вот говнокоды. Ухудшать компилятор из-за чужого говнокода -- это изначально деструктивная установка.
>> Но Ленин, как и разработчики gcc лишь выполнял свою задачу, они
>> не должны думать о таких побочных эффектах.
> Ленин - нет, а gccшники - да.
> Буквально год назад был пример с поломкой SPEC. Тоже ошибка в тесте,
> тоже ломает оптимизация gcc. Но при выборе "удавчик, крокодильчик или хомячок":
> исправление SPEC => все предыдущие результаты в унитаз, забить => gcc
> больше не проходит SPEC, вставить костыль; почему-то выбирают 3-й вариант.Не понимаю зачем к рассмотрению данной проблемы gcc-vs-bind приплетать другие gcc-related проблемы. Нет никакого желания обсуждать ещё один случай, пока ещё не закрыли обсуждение данного. Так мы бесконечно закопаемся.
>> Что такое "хрупкая" сборка? Естественно ветка вводимая в production должна работать надёжно.
>> А обычно это release-сборки, следовательно...
> Вы правильно всё поняли. Следовательно, debug мы компилируем с -O2, а release
> - с -O0? ;-)Серьёзно? Дико прошу простить за переход на личности, но вы вообще работали с HPC-кластерами? Или просто с высоконагруженными сервисами?
В общем, я с вами тут абсолютно не согласен. "-O2" нужен не только для тестов, но и для работы с адекватной скоростью.
> Мне, например, рассказывали про ситуации с маленькими автомобилями, которые не видно из
> больших автомобилей. Вроде как в рамках соблюдения ПДД образовывалась авария.Нет, не в рамках. Нарушен пункт "соблюдение дистанции". В ПДД есть неточности, но они значительно глубже. По-идее, если ПДД соблюдаются всеми и внешних воздействий нет, то аварий быть не может.
Надо переходить на зелёный свет, подняв голову к небу? Или мы всё же учитываем, что окружающие могут ошибаться?
> В чём разница? Замените "ты" на "авторы Maxima".
Он давно мёртв. Никаких претензий не принимает, всё что можно сделать - придти на могилу, положить цветы.
> Не пример для меня. Не пользовался такой программой. Однако, если код говно,
> то он -- говнокод. И виноваты в этом его авторы, а
> не авторы компиляторов.Да. Но очень полезный. Я пакетирую аналог, который очень хорошо написан. Но, увы, не везде дотягивает по функциональности.
> Это вообще не задача компиляторов подстраиваться под такие
> вот говнокоды. Ухудшать компилятор из-за чужого говнокода -- это изначально деструктивная
> установка.Не надо его ухудшать. Нужно по возможности учитывать наличие говнокода. Т.е. в данном месте вывесить большой красный флаг.
> Не понимаю зачем к рассмотрению данной проблемы gcc-vs-bind приплетать другие gcc-related
> проблемы. Нет никакого желания обсуждать ещё один случай, пока ещё не
> закрыли обсуждение данного. Так мы бесконечно закопаемся.Абсолютно аналогичный. Тоже проблема в коде, тоже оптимизация gcc.
> Серьёзно? Дико прошу простить за переход на личности, но вы вообще работали
> с HPC-кластерами?Прощаю. Там был знак вопроса, который вы на эмоциях не заметили.
> В общем, я с вами тут абсолютно не согласен. "-O2" нужен не
> только для тестов, но и для работы с адекватной скоростью.Да, да, да, мы это с вами ещё вчера перемыли. В ряде случаев -O2 по сравнению с -O0 у меня давало 5 раз.
>> Мне, например, рассказывали про ситуации с маленькими автомобилями, которые не видно из
>> больших автомобилей. Вроде как в рамках соблюдения ПДД образовывалась авария.
> Нет, не в рамках. Нарушен пункт "соблюдение дистанции".Нарушен в следствии полного следования ПДД каждым участником движения. Каждый реагировал на входящую информацию строго по книжке. То что была нарушена дистанция стало известно уже пост-фактум. В то время как когда полностью следуешь стандарту -- всё будет хорошо.
> В ПДД есть неточности,
> но они значительно глубже. По-идее, если ПДД соблюдаются всеми и внешних
> воздействий нет, то аварий быть не может.
> Надо переходить на зелёный свет, подняв голову к небу? Или мы всё
> же учитываем, что окружающие могут ошибаться?Некорректная аналогия. Если меня собьют, это нельзя будет починить. Если же bind допустил ошибку, у них будет полно времени это починить.
>> В чём разница? Замените "ты" на "авторы Maxima".
> Он давно мёртв. Никаких претензий не принимает, всё что можно сделать -
> придти на могилу, положить цветы.So what? Опять же причём тут разработчики gcc? Если проект полезный, то из комьюнити кто-нибудь подтянется, чтобы исправить необходимые баги. Если бесполезный, то и хрен с ним. Единственное что точно, это что разработчики gcc тут не при чём.
>> Не пример для меня. Не пользовался такой программой. Однако, если код говно,
>> то он -- говнокод. И виноваты в этом его авторы, а
>> не авторы компиляторов.
> Да. Но очень полезный. Я пакетирую аналог, который очень хорошо написан. Но,
> увы, не везде дотягивает по функциональности.Ок, но опять же это проблема лишь авторов и пользователей данной программы, но точно не проблема разработчиков компилятора (см. выше).
>> Это вообще не задача компиляторов подстраиваться под такие
>> вот говнокоды. Ухудшать компилятор из-за чужого говнокода -- это изначально деструктивная
>> установка.
> Не надо его ухудшать. Нужно по возможности учитывать наличие говнокода. Т.е. в
> данном месте вывесить большой красный флаг.Какой красный флаг? Разработчики gcc занимаются gcc. Тратить бесконечное количество ресурсов изучая каждый говнокод в Интернете -- это бесполезная трата времени. Если же вы хотите, чтобы он выводил какой-то дополнительный warning, то предложите это через maillist.
>> Не понимаю зачем к рассмотрению данной проблемы gcc-vs-bind приплетать другие gcc-related
>> проблемы. Нет никакого желания обсуждать ещё один случай, пока ещё не
>> закрыли обсуждение данного. Так мы бесконечно закопаемся.
> Абсолютно аналогичный. Тоже проблема в коде, тоже оптимизация gcc.Да, но тот случай тоже требует обсуждения. Лично для меня эта аналогия абсолютно бессмысленная, ибо тупо втягивает в ещё одно обсуждение, хотя мы ещё не закончили данное.
>> Серьёзно? Дико прошу простить за переход на личности, но вы вообще работали
>> с HPC-кластерами?
> Прощаю. Там был знак вопроса, который вы на эмоциях не заметили.
>> В общем, я с вами тут абсолютно не согласен. "-O2" нужен не
>> только для тестов, но и для работы с адекватной скоростью.
> Да, да, да, мы это с вами ещё вчера перемыли. В ряде
> случаев -O2 по сравнению с -O0 у меня давало 5 раз.5 раз -- это далеко не предел. Надеюсь мы определились, что "-O0" -- это не синоним production-way?
> Нарушен в следствии полного следования ПДД каждым участником движения. Каждый реагировал
> на входящую информацию строго по книжке. То что была нарушена дистанция
> стало известно уже пост-фактум. В то время как когда полностью следуешь
> стандарту -- всё будет хорошо.Либо "полное следование ПДД", либо "была нарушена дистанция", но не одновременно. ПДД не рассматривает "входные данные" - там всё равно, по какой причине вы не соблюдали дистанцию. Поэтому непосредственный виновник(и) всегда определяем(ы).
> Некорректная аналогия. Если меня собьют, это нельзя будет починить. Если же bind допустил ошибку, у них будет полно времени это починить.
а) Не всегда сбивают насмерть.
б) Если bind ушёл к потребителям, и у кого-то упал - это уже произошло. Т.е. "откатить обратно" не получится.
> So what? Опять же причём тут разработчики gcc?
Давайте отбросим наивность и будем рассуждать цинично. Мейнтейнеры дистрибутивов - люди ленивые, в массе своей они не будут проверять список оптимизаций введённых в новую версию gcc. Они, если не будет сообщений пользователей или какого-то хайпа, просто перекомпилируют свой софт с новым gcc и -O2 по-умолчанию.
Соответственно, с большой вероятностью, те оптимизации, которые gcc-шники вставляют в -O2, пройдут в софт без изменений. Т.е. gccшники имеют возможность непосредственно влиять на мировой софт. Это определённая власть.
Возвращаясь к maxima. Подобных проектов море. Во власти gcc-шников либо сделать их более хрупкими, либо менее хрупкими. При прочих равных более хрупкий код в эксплуатации хуже. Есть власть => есть ответственность.
> Если же вы хотите, чтобы он выводил какой-то дополнительный warning, то предложите это через maillist.
Это уже сделано. И предупреждение будет.
> 5 раз -- это далеко не предел. Надеюсь мы разобрались, что "-O0" -- это не синоним production-way?
Это ответ несколько не на тот вопрос. Тот - что делать с противоречием между хрупкостью release и стойкостью debug'а?
>> Нарушен в следствии полного следования ПДД каждым участником движения. Каждый реагировал
>> на входящую информацию строго по книжке. То что была нарушена дистанция
>> стало известно уже пост-фактум. В то время как когда полностью следуешь
>> стандарту -- всё будет хорошо.
> Либо "полное следование ПДД", либо "была нарушена дистанция", но не одновременно. ПДД
> не рассматривает "входные данные" - там всё равно, по какой причине
> вы не соблюдали дистанцию. Поэтому непосредственный виновник(и) всегда определяем(ы).Замечательно. А теперь объясните мне (тупому) где тут противоречье с тем, что написал я? — «Каждый реагировал на входящую информацию строго по книжке».
Есть разница между тем, чтобы определять своё поведение в соответствии с какими-то правилами (то есть следовать им), и тем, чтобы не допустить ниодного нарушения ниодного из правил.
Второе просто невозможно, в то время, как первое возможно в ПДД (как я его себе представляю). Дак вот если каждый будет добросовестно делать как написано в стандарте — это будет гарантией работы кода (при верном компиляторе), а вот если каждый будет делать как написано в книжке по ПДД, то в результате будет авария.
Следовать правилам и соблюдать их — вещи разные, хоть и похожие. Грубо говоря, следование правилам может привести в ситуацию, где авария ещё не произошла, но где её уже не избежать. То есть, грубо говоря, водители следовали правилам, но не соблюли их.
И я очень прошу, не надо спорить на тему терминов. Тут сейчас важнее мысль, которую я пытаюсь донести, что этот эффект есть в ПДД, но нет в стандартах программирования. И если вы мою мысль поняли, то сейчас важно только это, а не то, что же знажчат слова «соблюдать» и т.п. в обычной терминологии.
>> Некорректная аналогия. Если меня собьют, это нельзя будет починить. Если же 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? ;-)
Отвечаю: «Нет, не следовательно». Пояснения см. мой комментарий с моим изначальным ответом на данный вопрос.
> Замечательно. А теперь объясните мне (тупому) где тут противоречье с тем, что написал я? — «Каждый реагировал на входящую информацию строго по книжке».Не надо срываться на эмоции.
> Есть разница между тем, чтобы определять своё поведение в соответствии с какими-то правилами (то есть следовать им), и тем, чтобы не допустить ниодного нарушения ниодного из правил.
Есть разница. Поэтому ПДД сделаны с запасом - даже если их слегка нарушать, с огромной вероятностью аварии не произойдёт. А так - да, нарушают. Даже если отбросить нарушения скоростного режима, дисциплинированный водитель делает в среднем одно нарушение в 15 минут (разной степени серьёзности).
> Второе просто невозможно, в то время, как первое возможно в ПДД (как я его себе представляю).
Неправильно представляете. В ПДД нет такого понятия "строго следовать книжке". Не соблюдал дистанцию - виноват, а по какой причине - для ПДД неважно. Потому, что этот пункт внёс бы излишнюю субъективность.
>> В чём разница? Замените "ты" на "авторы Maxima".
> Он давно мёртв. Никаких претензий не принимает, всё что можно сделать -
> придти на могилу, положить цветы.Ой, а мужики-то не знают, уже 5.33 выпустили. И вообще по 4-5 раз в год новые версии выходят
> Ой, а мужики-то не знают, уже 5.33 выпустили. И вообще по 4-5
> раз в год новые версии выходятМужики, естественно, не знают о том, что происходило больше, чем 2 года назад. И что Максиму длительное время поддерживал ныне покойный William Schelter из Техаса - тоже не знают.