The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..., opennews (ok), 13-Июн-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


54. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –1 +/
Сообщение от pv47 (ok), 13-Июн-14, 17:32 
> компилятор не может, по компилируемому куску кода, самостоятельно определить, что эти переменные могут принять значение NULL

и поэтому удаляет код, который явно проверяет это и написан программистом, который МОЖЕТ это сделать самостоятельно. браво.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

106. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +2 +/
Сообщение от Orduemail (ok), 13-Июн-14, 23:31 
> написан программистом, который МОЖЕТ это сделать самостоятельно

Как факт, замечу, что программист не всегда это делает. Допустим есть функция:
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 функции для того и придумали, чтобы их инлайнил компилятор.

Зарубите себе на носу: программист -- это человек который крайне не любит делать что-либо самостоятельно, программист -- это человек, который уверен, что всё, что может быть автоматизировано, должно быть автоматизировано. Если человек в этом не уверен, то он не программист. В частности, если может быть автоматизировано выкидывание ненужных сравнений с нулём, то это должно быть сделано.

Ответить | Правка | Наверх | Cообщить модератору

107. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –1 +/
Сообщение от pv47 (ok), 14-Июн-14, 00:17 
> Допустим есть функция:

Я об этом как-то не подумал... хотя, ваш пример носит другой характер.

В вашем случае компилятор явно _видит_, что 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, который бы просто не оптимизировал подобные сомнительные случаи, т.е. перекладывал бы "неопределённое поведение" на процессор и библиотечные функции.

Ответить | Правка | Наверх | Cообщить модератору

113. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от Xasd (ok), 14-Июн-14, 04:16 
> идеальным вариантом стала бы поддержка какого-нибудь -fno-optimize-undefined-behavior, который бы просто не оптимизировал подобные сомнительные случаи ...

где ты *сомнительный* случай нашёл?

если программист сделал для структуры (foo)


x = foo->bar
// other code

значит компилятор *БЕЗ* каких либо сомнений знает что foo всегда != 0.

Ответить | Правка | Наверх | Cообщить модератору

119. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от arisu (ok), 14-Июн-14, 13:38 
> ИМХО, идеальным вариантом стала бы поддержка какого-нибудь -fno-optimize-undefined-behavior,
> который бы просто не оптимизировал подобные сомнительные случаи, т.е. перекладывал бы
> "неопределённое поведение" на процессор и библиотечные функции.

есть такой ключ! -O0!

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

108. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –1 +/
Сообщение от eganru (?), 14-Июн-14, 01:09 
по Вашему ассемблер так вообще для слабаков.
Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

283. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от Аноним (-), 16-Июн-14, 09:15 
>     return str ? str[0] : -1;

А это вообще нормально - возвращать str[0] который char как знаковый int? Нет, си конечно по факту так позволяет. Но, как бы это сказать, неаккуратненько...

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

301. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от arisu (ok), 16-Июн-14, 12:04 
> А это вообще нормально - возвращать str[0] который char как знаковый int?

нормально, говнокодеры говорят малацца.

Ответить | Правка | Наверх | Cообщить модератору

308. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от Orduemail (ok), 16-Июн-14, 21:47 
>>     return str ? str[0] : -1;
> А это вообще нормально - возвращать str[0] который char как знаковый int?
> Нет, си конечно по факту так позволяет. Но, как бы это
> сказать, неаккуратненько...

Ты знаешь назначение функции first? Видишь ли, при ней нет документационного комментария, поэтому я не знаю, для чего она вообще нужна. Если ты знаешь, расскажи мне, и мы обсудим, насколько уместно возвращение str[0].

Ответить | Правка | К родителю #283 | Наверх | Cообщить модератору

309. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  –1 +/
Сообщение от arisu (ok), 16-Июн-14, 22:18 
нинасколько, потому что никакой разумной причины возвращать или str[0] или -1 нет, ибо -1 входит во множество значений char. неразумных же причин можно выдумать много, но все они могут возникнуть только в говнокоде.
Ответить | Правка | Наверх | Cообщить модератору

310. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от Orduemail (ok), 16-Июн-14, 22:55 
> нинасколько, потому что никакой разумной причины возвращать или str[0] или -1 нет,
> ибо -1 входит во множество значений char. неразумных же причин можно
> выдумать много, но все они могут возникнуть только в говнокоде.

Отлично. Тогда я предлагаю переписать тот примерчик, дабы продемонстрировать оптимизацию на идеологически верном коде. Удивите нас.

Ответить | Правка | Наверх | Cообщить модератору

343. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от Crazy Alex (ok), 22-Дек-15, 15:33 
А что тут ненормального? Архитектур, где sizeof(char)==sizeof(int) уже и не осталось, разве что контроллеры какие-то. А для обычного рядового кода char, даже если он unsigned, в signed int поместится гарантированно.
Ответить | Правка | К родителю #283 | Наверх | Cообщить модератору

345. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от arisu (ok), 22-Дек-15, 21:30 
> А что тут ненормального?

как я уже писал, ненормально тут то, что -1 — валидное значение для char, который по умолчанию signed. как этот код ни переписывай, он изначально говнокод, потому что использует для исключительной ситуации код возврата, который может появиться и без исключительной ситуации. у программиста при виде этого в голове ревёт сирена. сразу. вне зависимости от того, может ли во входном потоке встретиться \xff — если это никак не проверяется, и даже комментария нет, то может, и встретится, и всё сломается.

это как не проверять результат malloc'а: глаз мгновенно спотыкается, а руки автоматически тянутся вставить хотя бы проверку с abort'ом.

Ответить | Правка | Наверх | Cообщить модератору

346. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от 0xd34df00d (??), 22-Дек-15, 21:31 
> char, который по умолчанию signed.

Нет, знаковость char зависит от платформы.

Ответить | Правка | Наверх | Cообщить модератору

347. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от arisu (ok), 22-Дек-15, 21:59 
>> char, который по умолчанию signed.
> Нет, знаковость char зависит от платформы.

на большинстве платформ у большинства компиляторов char по‐умолчанию знаковый. без явных дополнительных уточнений это принимается умолчанием.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру