The OpenNET Project / Index page

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



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

Оглавление

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

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


123. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/
Сообщение от клоун Стаканчик (?), 30-Окт-13, 17:40 
> if ((intptr_t)buf + len < buf)

Если len объявлена беззнаковым числом, то buf+len<buf ложно при любых значениях buf и len и проверка может быть сочтена избыточной.

Второй пример "упадёт" только если адрес 0000:0000 недоступен для чтения. Во многих ОС это так, но считать это аксиомой и закладывать в стандарты ЯП или в компилятор нельзя. Да, логичнее было бы изменить порядок следования операторов, но только это не делает код однозначно неправильным. Для сравнения: "c=a+b; if(!a)return;"

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

132. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от dq0s4y71 (ok), 30-Окт-13, 18:23 
> Если len объявлена беззнаковым числом, то buf+len<buf ложно при любых значениях buf
> и len и проверка может быть сочтена избыточной.

Почему это? Сравниваются ведь указатели, а не целые, поэтому целое будут преобразовано в указатель, а не наоборот.

> Для сравнения: "c=a+b; if(!a)return;"

Не совсем корректное сравнение. У этого кода нет побочных эффектов, в отличие от. Я бы предложил такое сравнение:

   (*funcptr)();

   if (!funcptr) ...


Тоже "корректно", но результат в большинстве случаев будет неожиданным :)

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

137. "Оптимизация кода компилятором может привести к появлению про..."  –2 +/
Сообщение от клоун Стаканчик (?), 30-Окт-13, 18:43 
Почему это? Сравниваются ведь указатели, а не целые, поэтому целое будут преобразовано в указатель, а не наоборот.

buf + len >= buf. Всегда для беззнакового len. Согласны? Преобразование типа данных - фиктивная процедура, предназначенная для контроля типов на уровне ЯП, которая не попадает (за редкими исключениями, напр. числа с плавающей точкой хранятся в FPU, а целые числа в регистрах общего назначения) в бинарный код.

> Не совсем корректное сравнение

Сравнение корректно в том плане, что в обоих случаях можно изменить порядок следования операторов, но нельзя убирать условие.

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

143. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Orduemail (ok), 30-Окт-13, 19:06 
> buf + len >= buf. Всегда для беззнакового len. Согласны?

Нет. Пример для 32-х битной платформы: buf=(void*) 0xffffffff; len=1

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

144. "Оптимизация кода компилятором может привести к появлению про..."  +3 +/
Сообщение от ананим (?), 30-Окт-13, 19:06 
Проводить сравнение методом «а давайте попробуем вызвать переполнение?» — идиoтизм.
Вы ещ на ноль делите, чтобы проверить, был там 0 или нет.

Вот корректная проверка (ULONG_MAX - buf) > len. И оптимизатор тоже идиoтизмoм её не посчитает. (или SIZE_MAX для size_t, или >= вместо >. Тут уж хозяин барин)

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

150. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Аноним (-), 30-Окт-13, 19:55 
> buf + len >= buf. Всегда для беззнакового len. Согласны?

Вот ты и показал что ты болванчик. Как ты думаешь, что будет если к 32-битному uint32 0xfffffffe прибавить uint32 0x3? Ничего что оно врапнется по 32-битной границе? В общем твоими программами я бы пользоваться не стал - ты самых основ программирования не знаешь.

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

159. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Аноним (-), 30-Окт-13, 20:27 
>> buf + len >= buf. Всегда для беззнакового len. Согласны?
> Вот ты и показал что ты болванчик. Как ты думаешь,

Так думает не он, разработчики компиляторов.

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

167. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от ананим (?), 30-Окт-13, 21:21 
Неа. Так думаешь ты и ахтур этого гoвнoкoда.
А компилятор думает а) С детишкам не игрушка и б) совсем тyпoй код надо выкинуть, если ахтур попросил его оптимизировать этот гoвнoкoд.
Ответить | Правка | Наверх | Cообщить модератору

170. "Оптимизация кода компилятором может привести к появлению про..."  +/
Сообщение от Аноним (-), 30-Окт-13, 22:08 
> Так думает не он, разработчики компиляторов.

На самом деле все проще: математика у процов так работает.

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

208. "Оптимизация кода компилятором может привести к появлению..."  +4 +/
Сообщение от arisu (ok), 31-Окт-13, 09:09 
>>> buf + len >= buf. Всегда для беззнакового len. Согласны?
>> Вот ты и показал что ты болванчик. Как ты думаешь,
> Так думает не он, разработчики компиляторов.

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

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

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

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

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




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

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