The OpenNET Project / Index page

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



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

Оглавление

Оптимизация кода компилятором может привести к появлению про..., opennews (?), 30-Окт-13, (0) [смотреть все]

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


48. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/
Сообщение от тоже Анонимemail (ok), 30-Окт-13, 14:12 
Если позволите, вопрос от не читавшего стандарт.
А что, в С разыменование указателя не сопровождается проверкой на NULL?
Что по ассемблерным понятиям это разыменование - это просто прибавление к указателю смещения члена структуры, это понятно. Но разве эта строчка при исполнении не должна вызвать сегфолт в любом случае?
Ответить | Правка | Наверх | Cообщить модератору

61. "Оптимизация кода компилятором может привести к появлению про..."  +2 +/
Сообщение от Анонимemail (61), 30-Окт-13, 14:40 
> А что, в С разыменование указателя не сопровождается проверкой на NULL?

Еще чего не хватало.

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

62. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Филипп Филиппович (ok), 30-Окт-13, 14:41 
Вы про нулевой указатель и tun->sk?

Да, там прибавление смещения. Но ведь даже прибавлять к нулевому указателю что-либо по стандарту, ЕМНИП, нельзя. И, кстати, что бинарно представляет собой этот нулевой указатель, иди разбери -- где как. Чтение чего-то по небольшому смещению -- вопрос, к чему приведёт, зависит от железки и ОС сильно. На свете полно платформ, где это просто тихо сработает, прочитав мусор. И полно таких, где нет. Кстати, указатель -- не всегда только смещение. Сейчас все привыкли в прикладных приложениях к тому, что мир плоский (неважно, 32 или 64 бита), а вообще-то часто есть ещё и сегмент. Во времена 8086/8088 повсеместно было иначе. Разные указатели, разные "модели памяти" для программ... В общем, не в любом случае это даст сегфолт.

Не говоря уже о том, что раньше оптимизатор мог работать иначе и тихо вырезать эту операцию вообще, но не считать её признаком, что указатель tun -- ненулевой. И, как следствие, не удалить проверку на ноль. Или переставить чтение и проверку. Он много чего мог.

И да, ПРОВЕРКОЙ разыменование не сопровождается. Это противоречило бы всему дизайну языка.


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

67. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/
Сообщение от Анонимemail (61), 30-Окт-13, 14:49 
> И, кстати, что бинарно представляет собой этот нулевой указатель, иди разбери -- где как.

На любой вменяемой платформе это 0.

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

76. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Филипп Филиппович (ok), 30-Окт-13, 15:01 
> На любой вменяемой платформе это 0.

Э, не спешите. Если в плоской модели, то наверное. Я другого ещё не видел, во всяком случае. Хотя никто этого не обещает, наверное, так будет. А вот если указатель включает в себя селектор сегмента и смещение, то каким будет этот селектор -- иди разбери. Возможно, каким-то таким, чтобы любая операция падала, не факт, что нулевым. Но это отдаётся на откуп железке-ОС-компилятору.


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

80. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Анонимemail (61), 30-Окт-13, 15:20 
Я же специально написал "на любой вменяемой платформе" :)
Ответить | Правка | Наверх | Cообщить модератору

118. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от dq0s4y71 (ok), 30-Окт-13, 17:30 
Вообще-то, на любой платформе это 0. Внутреннее представление значения не имеет. http://c-faq.com/null/ptrtest.html
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

128. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Филипп Филиппович (ok), 30-Окт-13, 17:59 
Ну я же говорил не о том, что оно сравнивается с нулём на C. Я говорил именно о том, что там бинарно, выше же так и написано.
Ответить | Правка | Наверх | Cообщить модератору

206. "Оптимизация кода компилятором может привести к появлению..."  +/
Сообщение от arisu (ok), 31-Окт-13, 09:03 
> Вообще-то, на любой платформе это 0. Внутреннее представление значения не имеет. http://c-faq.com/null/ptrtest.html

тут нюанс: NULL — это всегда 0, и всегда обозначает «негодный указатель». но обратное неверно: «негодный указатель» может и не быть NULL'ом (например, указывать на область памяти, которой нет).

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

71. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от тоже Анонимemail (ok), 30-Окт-13, 14:54 
Да, пардон, это я напутал. Никаких проверок в самом коде, конечно. Это система выдаст сегфолт, но, насколько я понимаю, только в случае попытки записи по этому адресу.
А так - получается вполне валидный код, который работает с началом памяти как с read-only структурой. На чтение она вполне может быть доступна.
Тогда непонятна как раз логика оптимизатора - с чего это он считает, что разыменованный указатель не может быть NULL, если на практике - может? Стандарт запрещает такую практику? Ну, так "PDF - это не то, что записано в спецификации, а то, что читает Adobe Reader" ;)
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

72. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Анонимemail (61), 30-Окт-13, 14:55 
> Да, пардон, это я напутал. Никаких проверок в самом коде, конечно. Это
> система выдаст сегфолт, но, насколько я понимаю, только в случае попытки
> записи по этому адресу.
> А так - получается вполне валидный код, который работает с началом памяти
> как с read-only структурой. На чтение она вполне может быть доступна.

Разумеется это не так.

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

74. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Филипп Филиппович (ok), 30-Окт-13, 14:58 
Нет, всё не так. :-) Очень много где будет защита и от чтения.

Стандарт такую практику, конечно, запрещает. Вернее, он ничего не запрещает, но честно говорит, что результат вам может не понравиться. Это и есть "результат неопределён", к слову. :-)

Результат неопределён = "это в разных реализациях может быть сделано по-разному, не рассчитывайте ни на что".

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

107. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Crazy Alex (ok), 30-Окт-13, 17:05 
На каком-нибудь эмбеде запись по нулевому адресу может быть абсолютно корректной. На AVR том же.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

127. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от dq0s4y71 (ok), 30-Окт-13, 17:56 
Такая запись, возможно, не вызовет исключения, но это не значит, что она будет корректной :)

В бытность МС-ДОСа, помнится, в борландовских рантаймах в начале сегмента данных была специальная область с контрольной суммой, которая пересчитывалась на выходе, и если ты писал что-то по нулевому указателю, тебе на выходе на консоль выдавалось предупреждение :)

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

135. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Crazy Alex (ok), 30-Окт-13, 18:25 
На AVR по нулевому адресу находится регистр R0. Читать/писать его таким образом абсолютно корректно.
Ответить | Правка | Наверх | Cообщить модератору

151. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Аноним (-), 30-Окт-13, 20:05 
> На AVR по нулевому адресу находится регистр R0. Читать/писать его таким образом
> абсолютно корректно.

AVR вообще гарвардец, по поводу чего у него несколько адресных пространств в самом явном виде. Флеш у него для кода (данные могут быть только константой и возвращаются оттуда весьма отдельным приседанием). А оператива - только для данных (и напрочь не может содержать код, что добавляет головняка в некторых случаях).

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

162. "Оптимизация кода компилятором может привести к появлению про..."  +1 +/
Сообщение от Crazy Alex (ok), 30-Окт-13, 21:01 
Угу, гаврвардец. Но ещё у него регистры спроецированы в адресное пространство. Что, в сущности, очень удобно иногда.

Но я всё это к тому, что неплохо бы помнить, что нулевой указатель - это не всегда ахтунг, и нельзя тупо запретить запись/чтение по нему и ругаться на это прямо в компиляторе.

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

169. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Аноним (-), 30-Окт-13, 21:45 
> Угу, гаврвардец. Но ещё у него регистры спроецированы в адресное пространство. Что,
> в сущности, очень удобно иногда.

Да, иногда это удобно :). Был тут один проц - ему переполнение буфера перезаписывало образ регистров в RAM. Это было весьма необычно. Правда, тот был неймановец.

> по нему и ругаться на это прямо в компиляторе.

Если в си позапрещать все потенциально опасные опции - как на нем тогда писать системные приблуды?

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

198. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от тоже Анонимemail (ok), 31-Окт-13, 08:35 
> Если в си позапрещать все потенциально опасные опции - как на нем тогда писать системные приблуды?

Два способа навскидку: ассемблерные вставки и какое-нибудь PRAGMA_I_KNOW_WHAT_I_DO - намек компилятору, что дальнейший код выше его понимания ;)

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

207. "Оптимизация кода компилятором может привести к появлению..."  +/
Сообщение от arisu (ok), 31-Окт-13, 09:05 
> Но я всё это к тому, что неплохо бы помнить, что нулевой
> указатель — это не всегда ахтунг, и нельзя тупо запретить запись/чтение
> по нему и ругаться на это прямо в компиляторе.

а это туда, к дизайнерам стандарта. NULL (оно же 0) — это «негодный указатель». всё. точка. негодный.

соответственно, если надо указать, что он годный — надо вводить какой-нибудь нестандартный атрибут.

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

322. "Оптимизация кода компилятором может привести к появлению..."  +/
Сообщение от Аноним (-), 02-Ноя-13, 10:17 
> «негодный указатель». всё. точка. негодный.

Дяденьки, идите нафиг. На сях можно и как-то так:
void* entry = (void *) 0x0;
int main()
{
goto *entry;
}
На это gcc даже warning не выдает. На писюке это конечно свалится по сегфолту, т.к. нету там никакого кода в 0x0, и вообще. А на половине микроконтроллеров по этому адресу будут вполне себе первые инструкции выполняемые после включения и это будет что-то типа ребута (не совсем идентичного аппаратному, но обычно это не принципиально). Если на системном языке так будет нельзя - какой же он системный? :)

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

325. "Оптимизация кода компилятором может привести к появлению..."  +/
Сообщение от arisu (ok), 02-Ноя-13, 11:02 
> На это gcc даже warning не выдает.

и не должно.

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

146. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Филипп Филиппович (ok), 30-Окт-13, 19:24 
Это к вопросу про то, какой указатель. Там было несколько моделей памяти, в том числе и такие, в которых все указатели были дальние (сегмент+смещение). И нулевой адрес в дальнем указателе указывал на начало таблицы прерываний.

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

205. "Оптимизация кода компилятором может привести к появлению..."  +/
Сообщение от arisu (ok), 31-Окт-13, 09:00 
> А что, в С разыменование указателя не сопровождается проверкой на NULL?

нет. этого делать нельзя, но по рукам никто не ударит, и код проверки тоже не вставят. точнее, по стандарту — не обязаны вставлять, это может быть дополнительной опцией компилятора. а может и не быть.

> разве эта строчка при исполнении не должна вызвать сегфолт в любом случае?

нет. более того, и не везде вызовет. в m$-dos, например, не вызовет. или в системе, где нет MMU и аппаратной защиты страниц.

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

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

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




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

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