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

"Оптимизация кода компилятором может привести к появлению про..."	+/–
Сообщение от opennews on 30-Окт-13, 12:07
Группа исследователей из Массачусетского технологического университета (MIT) опубликовала (http://www.itworld.com/security/380406/how-your-compiler-may...) (PDF (http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf), 240 Кб) результаты изучения особенностей работы систем оптимизации кода современных компиляторов, способных привести к понижению безопасности приложений. В итоге, выявлены многочисленные факты, когда в процессе компиляции в машинный код из приложения исключаются блоки, бессмысленные с точки зрения оптимизатора, но важные для обеспечения безопасности. Например, компилятор исключает неопределённые или нестабильные участки кода, которые на деле могут выступать проверками на появление нулевого указателя или выхода за границы области памяти. В итоге, данные проверки не включаются в исполняемый файл и безопасное на уровне исходных текстов приложение, становится подвержено уязвимостям на уровне исполняемого кода. Проблеме подвержено большинство современных компиляторов, включая GCC, Clang, ICC, MSVC, open64. pathcc, suncc и т.д. Например, оптимизатор GCC удалит вторую проверку из следующего кода: <font color="#461b7e">    char *buf = ...;    char *buf_end = ...;    unsigned int len = ...;    if (buf + len >= buf_end)       return;  /* len too large */    if (buf + len < buf)       return; /* overflow, buf+len wrapped around write to buf[0..len-1] */ </font> Также будет удалена проверка на нулевой указатель в коде: <font color="#461b7e">    struct tun_struct *tun = ...;    struct sock *sk = tun->sk;    if (!tun)       return POLLERR; /* write to address based on tun */</font> Для выявления потенциально проблемных мест в коде на языках C и C++, которые могут быть удалены на стадии оптимизации, исследователями подготовлен специальный статический анализатор STACK (http://css.csail.mit.edu/stack/). Изучение при помощи STACK типовых открытых проектов выявило 160 подобных проблем, из которых 32 присутствуют в ядре Linux, 3 в Mozilla, 9 в PostgreSQL и  5  в Python. Более широкая проверка исходных текстов показала, что нестабильные блоки кода присутствуют в 3471 пакете из 8575 пакетов, доступных в репозиториях Debian. Таким образом, описанные в работе  проблемы не являются единичными, а широко распространены и могут быть использованы злоумышленниками для организации новых типов атак. URL: http://www.itworld.com/security/380406/how-your-compiler-may... Новость: http://www.opennet.me/opennews/art.shtml?num=38293
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
Сообщение от Герберт Уэллс on 30-Окт-13, 12:07
До проверки на нуль выполнение не дойдёт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Оптимизация кода компилятором может привести к появлению про..."	+3 +/–
	Сообщение от Дмитрий (??) on 30-Окт-13, 12:23
	Если почитать оригинал (http://lwn.net/Articles/342330/) There is one little problem with that reasoning, though: NULL (zero) can actually be a valid pointer address. By default, the very bottom of the virtual address space (the "zero page," along with a few pages above it) is set to disallow all access as a way of catching null-pointer bugs (like the one described above) in both user and kernel space. But it is possible, using the mmap() system call, to put real memory at the bottom of the virtual address space. There are some valid use cases for this functionality, including running legacy binaries.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	53. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Герберт Уэллс on 30-Окт-13, 14:18
	Если бы мапирование в первые страницы действительно где-либо использовалось, то был бы приведён пример не tun драйвера, а этого софта. Мол, так и так, вот эти ребята написали аналог буст-шаред-мемори, для верности мапируем в ноль во всех процессах, использующих модуль.Это нет, и всем ясно почему: не было цепочки событий "ой что же это - не работает такой-то код! Давайте разберёмся почему" а была цепочка "ух ты! можно, оказывается, по нулевому адресу разместить данные! Но где бы мне это знание применить-то?".
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	299. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Ноя-13, 17:04
	> Если бы мапирование в первые страницы действительно где-либо использовалось, то был бы > приведён пример не tun драйвера, а этого софта. Мол, так и > так, вот эти ребята написали аналог буст-шаред-мемори, для верности мапируем в > ноль во всех процессах, использующих модуль.Это нет, и всем ясно почему: > не было цепочки событий "ой что же это - не работает > такой-то код! Давайте разберёмся почему" а была цепочка "ух ты! можно, > оказывается, по нулевому адресу разместить данные! Но где бы мне это > знание применить-то?". Ещё не так давно (пока не началась эпопея с уязвимостями, эксплуатирующими именно разыменование нулевого указателя) оно использовалось, например, в Wine...
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	65. "Оптимизация кода компилятором может привести к появлению про..."	+10 +/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 14:46
	Ну, написали бы тогда:     volatile struct tun_struct * tun = ...     volatile struct sock * sk = tun->sk; Компилятор вовсе не обязан знать, что при каких-то экзотических условиях кривой код всё-таки работает. Но компилятору можно об этом сообщить :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	217. "Оптимизация кода компилятором может привести к появлению про..."	+3 +/–
	Сообщение от pavlinux (ok) on 31-Окт-13, 14:52
	volatile const struct tun_struct const __restrict * const __attribute__((const), nocommon, mode(pointer)) tun = ... volatile const struct sock const __restrict * const __attribute__((const), nocommon, mode(pointer)) sk = tun->sk; :D
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	218. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 14:57
	> volatile const struct tun_struct const __restrict * const __attribute__((const), nocommon, > mode(pointer)) tun = … > volatile const struct sock const __restrict * const __attribute__((const), nocommon, mode(pointer)) > sk = tun->sk; > :D это будет покруче «Фауста» Гёте…
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

2. "Оптимизация кода компилятором может привести к появлению про..."	+3 +/–
Сообщение от Аноним (??) on 30-Окт-13, 12:13
если нет ошибки в программе, значит ошибка в компиляторе..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	240. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:13
	> если нет ошибки в программе, значит ошибка в компиляторе.. Ошибка в стандарте языка.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
Сообщение от BayaN (ok) on 30-Окт-13, 12:29
Приведены два примера неистового говнокода, в проблемах безопасности конечно виноват оптимизатор компилятора.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	59. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от анонимотик on 30-Окт-13, 14:39
	Комментор умнее исследователей и редакторов научных статей. Гений прям.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	70. "Оптимизация кода компилятором может привести к появлению про..."	+4 +/–
	Сообщение от noname01 on 30-Окт-13, 14:51
	> Комментор умнее исследователей и редакторов научных статей. Гений прям. Нет, все ещё круче. Если учитывать "3471 пакете из 8575 пакетов, доступных в репозиториях Debian" то комментатор просто сверх человек какой-то
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	75. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 14:58
	Чтобы подобным образом наезжать на комментатора, неплохо бы исследованиями заниматься и научные статьи писать, а не на постинг время тратить.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	103. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 16:51
	> Чтобы подобным образом наезжать на комментатора, неплохо бы исследованиями заниматься > и научные статьи писать, а не на постинг время тратить. Если комментатор пишет явную херню, проводить специальные исследования по данному вопросу - слегка оверкилл.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	181. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 23:13
	> Если комментатор пишет явную херню, проводить специальные исследования по данному вопросу - слегка оверкилл. Но можно по ссылке сходить и прочитать хотя бы первые буквы работы, которую "американские ученые" Си Вань и Николай Зельдович начали следующими словами: This paper studies an emerging class of SOFTWARE BUGS called optimization-unstable code: code that is unexpectedly discarded by compiler optimizations due to UNDEFINED BEHAVIOR IN THE PROGRAM. Т.е. они это называют багами в первой же фразе, и ни разу не утверждают, что проблема в компиляторах, а сразу говорят, что проблема - следствие неопределенного поведения в программе.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	233. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 15:56
	> Т.е. они это называют багами в первой же фразе, и ни разу > не утверждают, что проблема в компиляторах, а сразу говорят, что проблема > - следствие неопределенного поведения в программе. Оптимизация UB втихую - это, конечно, мудро и правильно. Вместо того, чтобы выдать предупреждение.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	243. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:26
	> Оптимизация UB втихую - это, конечно, мудро и правильно. Вместо того, чтобы > выдать предупреждение. в данном случае не было никакой «оптимизации UB»: включение оптимизатора изначально подразумевает, что ему на вход подаётся корректная программа. потому что ни один компилятор сей ничего не гарантирует в случае, когда оптимизатору скормили мусор. по мере сил компиляторы стараются предупреждать, но полноценный ИИ ещё не написали, так что получается у них не всегда.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	246. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:29
	> Оптимизация UB втихую - это, конечно, мудро и правильно. Вместо того, чтобы выдать предупреждение. Предназначение компилятора - компилировать, т.е. преобразовать исходный текст программы в исполняемый код согласно описанию/стандарту языка. Компилятор не обязан быть телепатом и пытаться сравнивать то, что Вы делаете, с тем, что Вы на самом деле хотели сделать. Для таких задач как раз есть всевозможные анализаторы, включая описанный в новости. Всё просто - если Вам нужен анализ Вашего кода на всевозможные проблемы - используйте анализаторы. Как ни странно, многие от компилятора ждут только компиляции, по возможности быстрой, и вовсе не хотели бы, чтобы он тратил время на размышления о том, что же имел в виду автор исходников.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	264. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 18:44
	> Как ни странно, многие от компилятора ждут только компиляции, по возможности быстрой, и вовсе не хотели бы, чтобы он тратил время на размышления о том, что же имел в виду автор исходников. А речь и не идет о философских размышлениях. Достаточно лишь довести до сведения автора, что он написал фигню.
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	336. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от IRASoldier on 18-Июн-18, 12:11
	>"американские ученые" Кавычки лишние. Работают и живут в США, значит американские. Что, бомбит?
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	85. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от BayaN (ok) on 30-Окт-13, 15:38
	Нет, просто комментатор на стороне создателей компиляторов, а не говнокодеров. Поэтому если стандарт Си позволяет компилятору выкинуть говнокод, то пусть выкидывает. Авторы же, не столь категоричны, поэтому решили немного разрядить войну компиляторы vs программисты, предоставив средства по обнаружению плохого кода. Это естественно позволит выводить красивые предупреждения и все будут счастливы. За это честь им и хвала. >The main contributions of this paper are: >• a new model for understanding unstable code, >• a static checker for identifying unstable code, and >• a detailed case study of unstable code in real systems.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	192. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:25
	> Комментор умнее исследователей и редакторов научных статей. Гений прям. в данном случае — умнее авторы компилятора. которые стандарты таки читали, в отличие от этих «исследователей».
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	234. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 15:57
	> в данном случае — умнее авторы компилятора. которые стандарты таки читали, в отличие от этих «исследователей». Стандарт прочитать и обезьянка может. А вот корректно обрабатывать отклонения от стандарта (например, выдавать предупреждения) - это уже мозг нужен. С чем, к сожалению, у авторов современных компиляторов проблемы.
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	248. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:35
	> Стандарт прочитать и обезьянка может. А вот корректно обрабатывать отклонения от стандарта > (например, выдавать предупреждения) — это уже мозг нужен. > С чем, к сожалению, у авторов современных компиляторов проблемы. предлагаю тебе надрать им всем задницы и показать, как надо делать компиляторы. раз ты так уверен, что ты сможешь научить компилятор выдавать предупреждения лучше, чем те, что есть — сделай это! заодно и «скайнет» напишешь, думаю.
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	258. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 17:00
	> раз ты так уверен, что ты сможешь научить компилятор выдавать предупреждения Ага, для того чтобы это хорошо работало, правда, придется тезисы Тюринга опровергнуть. Но об этом он узнает немного попозже...
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	260. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 17:52
	> Ага, для того чтобы это хорошо работало, правда, придется тезисы Тюринга опровергнуть. > Но об этом он узнает немного попозже… не веришь ты в людей. это, может, гений среди нас, а ты его расхолаживаешь. он тебя послушает-послушает, сопьётся с горя, умрёт — и не будет у нас «скайнета».
	Ответить | Правка | ^ к родителю #258 | Наверх | Cообщить модератору

	268. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 18:51
	>> раз ты так уверен, что ты сможешь научить компилятор выдавать предупреждения > Ага, для того чтобы это хорошо работало, правда, придется тезисы Тюринга опровергнуть. Вас послушать, так для оптимизаций компилятор вообще должен собственным сознанием обладать. А типичные случаи UB хорошо известны и разжеваны. С их отловом справился бы даже очень тyпой компилятор.
	Ответить | Правка | ^ к родителю #258 | Наверх | Cообщить модератору

	270. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 19:00
	> А типичные случаи UB хорошо известны и разжеваны. С их отловом справился > бы даже очень тyпой компилятор. так когда релиза-то ждать «нетупого компилятора»?
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

	301. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 01-Ноя-13, 18:55
	> так когда релиза-то ждать «нетупого компилятора»? Я решил эту проблему более эффективным способом :)
	Ответить | Правка | ^ к родителю #270 | Наверх | Cообщить модератору

	308. "Оптимизация кода компилятором может привести к появлению..."	+2 +/–
	Сообщение от arisu (ok) on 01-Ноя-13, 19:15
	>> так когда релиза-то ждать «нетупого компилятора»? > Я решил эту проблему более эффективным способом :) ага: балабольским. побалаболил и сбежал.
	Ответить | Правка | ^ к родителю #301 | Наверх | Cообщить модератору

	102. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 16:49
	> Приведены два примера неистового гoвнокода На сях гoвнокод, как правило, является наиболее простым и эффективным решением проблемы. Так что его надо любить и лелеять, как священную корову. Особенно на уровне компилятора.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	193. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:27
	> На сях гoвнокод, как правило, является наиболее простым и эффективным решением проблемы. это просто потому, что у тебя мозг кроме говнокода ничего больше произвести не в состоянии. вот ты и считаешь, что это не у тебя в голове кю, а просто кю — такое решение всех проблем.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	232. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 15:54
	> это просто потому, что у тебя мозг кроме гoвнокода ничего больше произвести не в состоянии. Не только у меня. Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	239. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:13
	> Не только у меня. Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод. Поэтому сам я стараюсь на сях не писать. Благо, задачи не системные, и перл отлично справляется.
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	257. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:58
	> и перл отлично справляется. Жаль что на перле операционки не пишут, правда? :)
	Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

	265. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 18:46
	> Жаль что на перле операционки не пишут, правда? :) Когда-нибудь найдется один ценитель истинного юниксвея, а не фанат блобов, и вот тогда...
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	312. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 00:16
	> Когда-нибудь найдется один ценитель истинного юниксвея, а не фанат блобов, и вот тогда... Тогда ты поймешь насколько "удобно" в perl делать вещи типа "записать бит 5 в единицу по адресу памяти 0x100500 для информирования девайса о том что драйвер подготовил ему данные".
	Ответить | Правка | ^ к родителю #265 | Наверх | Cообщить модератору

	302. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 01-Ноя-13, 18:56
	>> и перл отлично справляется. > Жаль что на перле операционки не пишут, правда? :) Ага. Тока на Lua :(
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	249. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:37
	>> это просто потому, что у тебя мозг кроме гoвнокода ничего больше произвести не в состоянии. > Не только у меня. Сколько сишных программ не смотрел — никогда не > видел, чтобы был не гoвнокод. бедняга. плохо быть тобой.
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	269. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 18:54
	> бедняга. плохо быть тобой. Не только мной. > Более широкая проверка исходных текстов показала, что нестабильные блоки кода присутствуют в 3471 пакете из 8575 пакетов, доступных в репозиториях Debian.
	Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

	313. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 00:42
	> Не только мной. FYI, баги встречаются не только в программах на си :).
	Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

	256. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:58
	> Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод. Я прямо удивляюсь даже - какой же операционкой вы тогда пользуетесь? И если они все плохие - ну вы нам покажете как их лучше писать, или как? :)
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	266. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 18:47
	>> Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод. > Я прямо удивляюсь даже - какой же операционкой вы тогда пользуетесь? А я не перфекционист :)
	Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

	314. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 00:44
	> А я не перфекционист :) Более того, сажать баги можно на любом ЯП. Некоторые из них будут вести к проблемам безопасности. Вообще, умиляет наивное хомячковое хотение чтобы умный компьютер думал вместо глупого программиста сам. Если бы это было так просто - глупый программист вообще отправился бы подметать улицы.
	Ответить | Правка | ^ к родителю #266 | Наверх | Cообщить модератору

	109. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 17:07
	Константин Серебряный, залогиньтесь
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	304. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 01-Ноя-13, 18:59
	> Константин Серебряный, залогиньтесь А кто это? Герой повести А.Толстого?
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

7. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
Сообщение от Аноним (??) on 30-Окт-13, 12:31
Компиляторы стали слишком умными, началась игра кто кого...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	190. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Led (ok) on 31-Окт-13, 04:11
	> Компиляторы стали слишком умными, началась игра кто кого... Относительно. Потому как кодеры в среднем стали на порядок тупее.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	194. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:27
	> Компиляторы стали слишком умными нет, это говнокодеры продолжают считать, что учить ПДД перед тем, как сесть за руль — излишество.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	236. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:07
	>> Компиляторы стали слишком умными > нет, это гoвнокодеры продолжают считать, что учить ПДД перед тем, как сесть > за руль — излишество. Тупое следование ПДД чревато. Если бы пользующиеся преимуществом водители (при перестроении, на главной, при выезде с прилегающих) никогда не уступали тем, кто не имеет преимущества - пробки были бы раз в десять больше, чем сейчас.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	250. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:38
	>>> Компиляторы стали слишком умными >> нет, это гoвнокодеры продолжают считать, что учить ПДД перед тем, как сесть >> за руль — излишество. > Тупое следование ПДД чревато. так же, как и тупые автомобильные аналогии. каюсь, сам первый начал.
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	267. "Оптимизация кода компилятором может привести к появлению..."	–2 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 18:49
	> каюсь, сам первый начал. Профессиональный сишник может наступить на грабли даже на ровном месте :) Сначала сам их напишет, потом наступит.
	Ответить | Правка | ^ к родителю #250 | Наверх | Cообщить модератору

	315. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 00:46
	> Сначала сам их напишет, потом наступит. А иные будут грести листья лопатой, как дeбилы. Потому что грабли видите ли вообще не предусмотрели, а сделать самому - обломно. Вот и приходится эмулировать их из того что есть...
	Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

8. "Оптимизация кода компилятором может привести к появлению про..."	+5 +/–
Сообщение от BSA on 30-Окт-13, 12:36
А причем тут компиляторы? Вместо того, чтобы проверить len, проверяется выход указателя за пределы выделенной области. Если в стандарте языка указано, что результат операции переполнения не определен, то нет ничего криминального в том, что компиляторы этим пользуются. Другое дело, что могли бы выдавать предупреждение в этом случае. Это косяки программистов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Оптимизация кода компилятором может привести к появлению про..."	–4 +/–
	Сообщение от z (??) on 30-Окт-13, 12:58
	>Вместо того, чтобы проверить len, проверяется выход указателя за пределы выделенной области. А если этот len добавляется к buf в каждой итерации? Умник такой умник
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	32. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от ананим on 30-Окт-13, 13:41
	Покажите такой код, где нужно в цикле к указателю постоянно добавлять число и я скажу в каком месте и насколько он гoвнo.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	87. "Оптимизация кода компилятором может привести к появлению про..."	–3 +/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 15:43
	; копирование первого поля структуры struct data dd data1 dd data2 ends @@: movsd add esi,4 ; <<<< loop @b ; ACPI: таблица RSDT состоит из последовательно идущих структур разного размера, каждая из которых имеет стандартный заголовок struct ACPI_HEADER db size ends xor eax,eax mov esi,[RSDT] mov edi,[RSDT_TABLE_SIZE] @@: call parse_ACPI_table lodsb add esi,eax ; <<<<< cmp edi,edi jb @b
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	92. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от ананим on 30-Окт-13, 16:01
	Хинт: Сабж (и данный трэд) о С... в крайнем случае о С++. ПС: понятно что в ассемблере без готу и условных джампов (включая флаги переполния) никуда. Более того, скомпилённый из С/С++ (да из любого языка!) код ими просто напичкан, но... трэд про язык С/С++ и линейную зависемость его оптимизации от уровня быдлoкoда. ППС: жалко что у индусов нет понятия быдлoкoд... они искренне не понимают за что их ругают. Вот и к нам скоро покатятся. Будут нас учить программировать и как за 50'000 рупий работать сеньором-девелопером.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	97. "Оптимизация кода компилятором может привести к появлению про..."	–3 +/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 16:18
	Пример 1: // ACPI: таблица RSDT состоит из последовательно идущих структур разного размера, каждая из которых имеет стандартный заголовок struct ACPI_HEADER { int size; } ... ACPI_HEADER *ptr; ... while(ptr < rsdt_end) { parse_ACPI_table(ptr); ptr += ptr.size; // <<<<<<< } Пример 2: в присланном файле каждая запись выровнена на N байт. Записи идут последовательно и имеют непостоянный размер. Напр. линии картинки имеют фиксированный размер и выровнены на 16 байт, записи в самописной файловой БД имеют переменный размер и выровнены на 4096, и т.д.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	104. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от ананим on 30-Окт-13, 16:52
	1. Ещё раз (для упoрoтых), Об аспи речи не шло. аспи кривое по-жизни. даже создатели признают. мс вон в 8 отказывается. в частности подсветка экрана. (не было в моей практике случая, чтобы аспи-таблицы с ноута, созданные мс-компилятором аспи, а это в районе 100%, проходили валидацию интеловским компилятором sys-power/iasl) 2.    а) Очевидно, читать структурированные (и выровненные!) данный (из файла или из аспи таблиц) лучше и удобнее в структуры. списки (возможно двух-связные) подойдут для С, контейнеры из стл подойдут для С++. Представленный быдлoкoд остаётся в силе.    б) где в вашем примере #1 проверка на допустимость значений? Потому что она не нужна (знаете почему?). (как поймёте, придёте к этому)К сабжу и трэду НЕ имеет отношения.    в) пример #2 ни о чём. уровень быдлoкoда определить не возможно в силу сферичности примера.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	114. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от z (??) on 30-Окт-13, 17:21
	>1. Ещё раз (для упoрoтых), Об аспи речи не шло. Для употорых: аспи лишь один из примеров, взять любые данные, упакованные в структуры переменной длинны - и будет вам ещё тысяча примеров >а) Очевидно, читать структурированные (и выровненные!) данный (из файла или из аспи таблиц) лучше и удобнее в структуры. Это в вашем идеальном сефрическом мире структуры всегда одной длинны и их число известно заранее, только реальность с вами почему-то не согласана
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	119. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ананим on 30-Окт-13, 17:31
	Для дабл-употорых: Так где в коде проверки? Почему их нет? Зыж То что их нет означает что к сабжу и трэду не имеют отношения. Вопрос — почему? То что существует арфметика над указателями и без вас ясно. Вопрос выше.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	195. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:30
	> Для дабл-употорых: > Так где в коде проверки? Почему их нет? потому что про проверки никто не спрашивал. просили пример кода, где «в цикле к указателю надо прибавлять число». пример привели.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	211. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от ананим on 31-Окт-13, 12:53
	серьёзно? вот ветка: >>>А причем тут компиляторы? Вместо того, чтобы проверить len, проверяется выход указателя за пределы выделенной области. >>А если этот len добавляется к buf в каждой итерации? Умник такой умник >Покажите такой код, где нужно в цикле к указателю постоянно добавлять число и я скажу в каком месте и насколько он гoвнo. При чём последнее — это моё. И я уж точно знаю что просил. зыж А вы что, хотите доказать, что адресная арифметика существует? Спасибо вам, вы открыли мне глаза. :D ззыж Кстати, так никто и не показал код, где в каждой итерации есть адресная арифметика с потенциальным переполнением.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	255. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:56
	> где «в цикле к указателю надо прибавлять число». пример привели. А также например декомпрессоры LZ не гнушаются таких вещей ради эффективности и скорости. Ясен перец, в нужных местах проверки на подлянки есть.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	130. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ананим on 30-Окт-13, 18:10
	1. В каком месте компилятор меняет исходники? 2. Когда вы предоставили с-код, требующий проверки валидатности в цикле с агрегацией указателей (потому что вы были настолько тупы, что реализовали такой механизм, который в каждой итерации может вывалится в оверфлоу)? 3. Откуда именно вы взяли этот быдлoкoд? 4. Почему в сырцах ядра такого трэша нет? (см. ниже) зыж >Мне надоели люди которые ноют, оскорбляют других или считают с Как мне надоелю люди, которые считают что приведённый ими быдлoкoд а) не имеет другого решения, б) вообще соответсвует обсуждаемому вопросу.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	131. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ананим on 30-Окт-13, 18:20
	ззыж Вот и покажи где тут бегают по указателям, потенциально выходящим за пределы #define ACPI_MEMCPY(d,s,n)      (void) memcpy((d), (s), (acpi_size)(n)) #define ACPI_ALLOCATE(a)        acpi_ut_allocate((acpi_size) (a), ACPI_MEM_PARAMETERS) … * FUNCTION:    acpi_tb_copy_dsdt * DESCRIPTION: Implements a subsystem option to copy the DSDT to local memory. *              Some very bad BIOSs are known to either corrupt the DSDT or *              install a new, bad DSDT. This copy works around the problem. struct acpi_table_header *acpi_tb_copy_dsdt(u32 table_index) {         struct acpi_table_header *new_table;         struct acpi_table_desc *table_desc;         table_desc = &acpi_gbl_root_table_list.tables[table_index];         new_table = ACPI_ALLOCATE(table_desc->length);         if (!new_table) {                 ACPI_ERROR((AE_INFO, "Could not copy DSDT of length 0x%X",                             table_desc->length));                 return (NULL);         }         ACPI_MEMCPY(new_table, table_desc->pointer, table_desc->length);         acpi_tb_delete_table(table_desc);         table_desc->pointer = new_table;         table_desc->flags = ACPI_TABLE_ORIGIN_ALLOCATED;         ACPI_INFO((AE_INFO,                    "Forced DSDT copy: length 0x%05X copied locally, original unmapped",                    new_table->length));         return (new_table); }
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	136. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 18:31
	1. компилятор исключил условие 2. на что вы "требуете" проверять? Не выделил ли malloc память, частично находящуюся за предел адресного пространства? Или что ACPI находится где-то в адресном пространстве (даже за пределами реальных адресов) памяти? Нет, не проверяю. Смысла нет. Вы должно быть удивитесь, но в моих "внутренних" (неэкспортируемых и не работающих с внешними данными) функциях нет проверки входных параметров, потому что я и так знаю какие параметры я передаю. 3. написал когда писал сообщение на этом форуме. Странный вопрос... 4. а вы читали код ядра? И вопрос не в том есть другое решение или нет, вопрос в том, на основании чего вы (я, он, компилятор) считаете данное решение неверным. И в этом же суть обсуждаемого вопроса. Напр. второй пример: sk = tun->sk; if(!tun)return; Если чтение адреса 0000:0000 возможно, то этот код верен. А возможно ли чтение или нет определяется ОС, а не стандартами ЯП. Для сравнения: c = a+b; if(!a)return; В обоих случаях можно изменить порядок следования операций, но нельзя исключать условие.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	139. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ананим on 30-Окт-13, 18:51
	>2. на что вы "требуете" проверять? Не выделил ли malloc память, частично находящуюся за предел адресного пространства? На оверфлоу указателя. По поводу чего и был трэд пока вы не пришли (с темой "к указателям можно прибавлять". А то мы до вас не знали). Ещё раз, крайний, если вы занимаетесь арифметикой указателей в цикле и каждая итерация потенциально вызывает оверфлоу, то ваш алгоритм не верен, а код — быдлoкoд. Зыж И да. Компилятор (вернее оптимизатор) исключил условие заслуженно. Сабж полезен по поводу локализации быдлoкoда. И код ядра читал. Только что, и про dsdt, и про rsdt, и про xsdt,... Всё аналогично и логично — вначале проверки, потом разбор (с циклами и тд.) Единственная проверка — таблица может быть нулевая, но это явно не сабж.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	142. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 19:06
	> На оверфлоу указателя 32-разрядное адресное пространство ограничено 2^32 степени адресов. При этом данные могут располагаться за пределами физической памяти. На какой "оверфлоу" планируете проверять? Адрес гарантировано находится в пределах 32-разрядного адресного пространства, т.к. хранится в 32-битовой парамере. Адрес может находиться за пределами физической памяти, а узнать размер области, находящейся за пределами физической памяти, невозможно. Приведённый выше код ядра копирует данные в новое место. Я, правда, не знаю зачем хранить две идентичные копии данных и тратить время на копирования, но это уже другой вопрос. Единственная проверка - PAGE FAULT, но она выполняется аппаратно.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	153. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 20:15
	> адресного пространства, т.к. хранится в 32-битовой парамере. Адрес может находиться за > пределами физической памяти, Программа в юзерспейсе в общем случае понятия не имеет о том какая там память. Это уже не ее проблемы. А операционки и ее механики paging'а. Виртуальный адресспейс на 32-битной архитектуре вполне себе 32-битный. А обращения по конкретным адресам приведут в разные закоулки виртуального адресспейса. При этом, очевидно, 32-битная программа не может адресовать более 4 Гб. Даже если они в системе и есть, 32-битная программа никогда не получит доступ к более чем 4Гб. К тому же часть виртуального адресспейса зарезервирована системой (как правило 1 или 2 Гб). Совсем низкоуровневые сущности могут работать и без трансляции адресов, оперируя физическими адресами влобовую, в данном случае адрес может быть чем угодно, может и совсем не памятью, например. Но опять же - более 4Гб без диких костылей типа PAE заадресовать не получится.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	171. "Оптимизация кода компилятором может привести к появлению про..."	–3 +/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 22:14
	Программам в "юзерспейсе" нет необходимости проверять на выход за пределы адресного пространства. Есть адресное пространство (для 32 бит адреса это 4 Гб). Есть физическая память, напр. планка на 128 Мб. Тем не менее можно обращаться к адресам памяти, лежащими за пределами физической (в нашем примере это 128 Мб) памяти. Это называется MMIO (memory mapped input-output), когда процессор воспринимает обращение к некоторым адресам памяти как обращение к некоторых другим параметрам, напр. видеопамяти, шине PCI, ROM BIOS, Local APIC, IO APIC, и т.д. "ананим" хотя бы в теме, вы - полный ноль. Адресация памяти к данному обсуждению отношения не имеет. Кстати, вы там тоже сильно плаваете, так PAE не является "дикими костылями", а наоборот представляет собой элегантный и очень эффективный механизм, позволяющий адресовать до 256 Гб памяти в 32-разрядном адресном пространстве.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	183. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 23:43
	> Кстати, вы там тоже сильно плаваете, так PAE не является "дикими костылями", а наоборот представляет собой элегантный и очень эффективный механизм, позволяющий адресовать до 256 Гб памяти в 32-разрядном адресном пространстве. Кажется, Линус тоже "плавает" - он почему-то не совсем согласен насчет элегантности и эффективности PAE: "PAE really really sucks. ... Whoever came up with the idea was totally incompetent, and had forgotten all the DOS HIGHMEM pains. There’s a damn good reason why we left the 286 behind, and started using 386′s, instead of having HIGHMEM crap with windows into a bigger physical space. ... So repeat after me: PAE didn’t ever really fix anything. It was a mistake. It was just a total failure, and the result of hw engineers not understanding software." http://www.realworldtech.com/forum/?threadid=76912&curpostid...
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	187. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от клоун Стаканчик on 31-Окт-13, 02:54
	Тогда предложите свой гениальный способ страничной адресации 256 Тб памяти (64 бита) с возможностью управления страницами размером 4 кб. До этих пор приведённое высказывание считаю пустобрёхством.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	189. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 03:47
	> Тогда предложите свой гениальный способ страничной адресации 256 Тб памяти (64 бита) "256 Тб памяти (64 бита)" - это как раз не про режим PAE, а про "гениальный способ", известный под названием AMD64.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	210. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от клоун Стаканчик on 31-Окт-13, 10:14
	Прежде чем продолжать, узнайте что такое PAE, long mode и AMD64.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	212. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 31-Окт-13, 12:55
	> Тогда предложите свой гениальный способ страничной адресации 256 Тб памяти (64 бита) > с возможностью управления страницами размером 4 кб. Зачем?  Про накладные расходы на страницах минимального размера не думали и про hugepages не слышали? Понимаю, что дурак может поставить дурацкую задачу и по-дурацки её решить -- а нормальный человек вместо поиска решения дурацкой задачи посмотрит в корень. Тормозное оно, это ваше PAE.  Что на x86, что на ARM, куда этот костыль замечательно следом втащили, хотя и на x86 до того было две итерации (с костылями в виде high/extended/expanded memory в 16-битные времена). Дикие потери производительности неудивительны при лазании через бутылочное горлышко.  А для I/O с некоторых железок окошко ещё и ниже гигабайта держать приходится, насколько помню. Понятно, что даже так лазить в память было всё же веселей, чем на диск -- почему для всяких PCTeX и делали своп на рамдрайве (официальная рекомендация).  Костыль от этого не становится элегантной тростью.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	185. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 31-Окт-13, 00:37
	> вы там тоже сильно плаваете, так PAE не является "дикими костылями", а наоборот Занавес. Наверное, это такие люди просовывают через PCI данные побитно, дёргая на каждый бит прерывание.  "Элегантно и очень эффективно".
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	226. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 15:43
	> Программам в "юзерспейсе" нет необходимости проверять на выход за пределы > адресного пространства. Как-то так переполнения буферов и случаются. Что, ты совсем не в состоянии осознать что buf+len при достаточно большом len спокойно отврапится и ... станет достаточном малым числом для того чтобы пройти проверку? :). У сишечки есть бестолковость - перенос (carry) или переполнение, когда результат математики получился больше чем размерность типа - никак не обрабатывается. Результат тихонько обрубается до размерности типа. В результате становится можно обойти проверку на выход за границу массива, впарив настолько большой len что сумма buf+len станет малым числом из-за враппинга, ну и дальше оно пройдет проверку. Пример от граждан - пытался поймать этот случай. Сама по себе идея - вполне валидна. Но вот ее реализация - полный ахтунг! > 128 Мб) памяти. Это называется MMIO (memory mapped input-output), когда процессор > воспринимает обращение к некоторым адресам памяти как обращение к некоторых другим > параметрам, напр. видеопамяти, шине PCI, ROM BIOS, Local APIC, IO APIC, Тут как-то в кучу смешано все и сразу. Без понимания того что кернел мод и юзер мод - разные вещи. Без понимания того что есть paging. Без понимания того что есть трансляция логических адресов в физические. > собой элегантный и очень эффективный механизм, позволяющий адресовать до 256 Гб > памяти в 32-разрядном адресном пространстве. Очень элегантный, ага, на фоне просто лобового вбабахивания 64-битного адреса как 64-битное целов.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	197. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:32
	> На какой «оверфлоу» планируете проверять? … > хранится в 32-битовой парамере ты риальне клоун.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	196. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:31
	> Если чтение адреса 0000:0000 возможно, то этот код верен. А возможно ли > чтение или нет определяется ОС, а не стандартами ЯП. вообще-то, разыменование NULL — это ошибка *по стандарту языка*, угу.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	227. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 15:44
	> вообще-то, разыменование NULL — это ошибка *по стандарту языка*, угу. Разыменование - да. А сам по себе доступ - не обязательно.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	251. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:39
	>> вообще-то, разыменование NULL — это ошибка *по стандарту языка*, угу. > Разыменование — да. А сам по себе доступ — не обязательно. расскажи мне, о Гуру, как можно делать «доступ» без разыменования.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	317. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 09:09
	> расскажи мне, о Гуру, как можно делать «доступ» без разыменования. Упс, перепутал с обращением к освобожденной памяти. Нефиг сообщения сонным писать. Тем не менее, работа с 0-м адресом может быть 100% валидна. Как-то так: void* entry = (void *) 0x0; ... goto *entry; Вполне валидная конструкция: на половине мелких девайсов проц начинает выполнение с 0x0 и это будет что-то типа программного ребута (например, вход из основной программы в bootloader чтобы прошивку обновить). Это с чего бы так должно быть нельзя на уровне системного языка?
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	324. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 02-Ноя-13, 10:58
	я же не спорю, что на уровне аппаратуры может быть валидной.
	Ответить | Правка | ^ к родителю #317 | Наверх | Cообщить модератору

	184. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 00:11
	Кого именно умнее, тебя клоун? Так это дело нехитрое. Тебе уже жирно намекали на то, что ты никаких проверок в своём коде не проводишь, поэтому тебя проблемы с выброшенной оптимизатором проверкой на переполнение не касаются. А ассемблер вообще не оптимизируется никак, переводится в код так, как есть. Хотя, даже такой клоун, как ты, бывают правы, когда компилятор выбрасывает код программиста, это никуда не годится. На худой конец, компилятор при оптимизации должен об этом очень громко орать.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	164. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 21:07
	Ну-ну, расскажите миру, в каком месте это верно про цикл, итерирующий массив структур, инкрементируя указатель.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	12. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:00
	Это косяки ЯЗЫКА. Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	13. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:07
	Аноним такой "знаток", что не в силах отличить недостатки от достоинств?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	34. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:44
	Может быть ты в силах? :)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	35. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:44
	> Аноним такой "знаток", что не в силах отличить недостатки от достоинств? А, так возможность переполнения - это на самом деле достоинство? Как и создаваемая им дыра в безопасности?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	38. "Оптимизация кода компилятором может привести к появлению про..."	+3 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:46
	>Как и создаваемая им дыра в безопасности? Для кого дыра, а для кого и мать родна :)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	305. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 01-Ноя-13, 19:00
	>>Как и создаваемая им дыра в безопасности? > Для кого дыра, а для кого и мать родна :) Намек на АНБ?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	64. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 14:46
	да. Это следствие ручного управление памятью. Такое же как низкое ее потребление, например.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	221. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от еще один аноним on 31-Окт-13, 15:11
	не путай "следствие" с "достоинством". Это разные понятия
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	238. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:11
	> да. Это следствие ручного управление памятью. Возможность целочисленного переполнения - это _не_ следствие ручного управления памятью.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	154. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 20:18
	> А, так возможность переполнения - это на самом деле достоинство? Это всего лишь то как по факту работают процессоры в массе своей. Обойти сие можно, но сложно и получится тормозная и многоэтажная этажерка из кода вместо 1 простой и быстрой команды проца. Си таки не язык для идиoтов. Для таких есть JS, питон и прочие, где пинками в стойло загоняют. А на си априори можно делать небезопасные вещи. Что делает его удобным выбором для системного программирования. Потому что записать число 0x20 по адресу 0x100500 на сях совершенно не проблема. А вот на других ЯП это уже потребует нифиговых костылей...
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	166. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от chinarulezzz (ok) on 30-Окт-13, 21:15
	>т. А на си априори можно делать небезопасные вещи. Что делает его удобным выбором для системного программирования. Потому что записать число 0x20 по адресу 0x100500 на сях совершенно не проблема. А вот на других ЯП это уже потребует нифиговых костылей... пффф)) modula-2(3), oberon.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	229. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 15:46
	> пффф)) modula-2(3), oberon. Я и смотрю - то-то все низкоуровневые и системные дела на них написаны. Ядра, бутлоадеры, фирмвары эмбедовочные, угу. Ну, пользуй наздоровье, мне что, жалко чтоли? А в упомянуых вещах столько методов прострела пяток что упомянутый - вообще так, мелочи жизни.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	242. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:23
	> Я и смотрю - то-то все низкоуровневые и системные дела на них написаны. не тупи, пожалуйста. надо ли в очередной раз пояснять, что популярность не обязательно коррелирует с удобством? да, на обероне написана ажно целая ось, с гуями. и на Active Oberon тоже ось, и с весьма навёрнутыми гуями. просто оберон и AO никто не популяризировал. да к тому же у них «синтаксис паскалевский, фи, отстой!»
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	300. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от Аноним (??) on 01-Ноя-13, 18:54
	> да к тому же у них «синтаксис паскалевский, фи, отcтой!» А не вы ли случайно употребляли выражение "гвидобейсик" в адрес пистона?
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	309. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 01-Ноя-13, 19:15
	>> да к тому же у них «синтаксис паскалевский, фи, отcтой!» > А не вы ли случайно употребляли выражение «гвидобейсик» в адрес пистона? и что характерно — вовсе не за синтаксис. сюрприз, да?
	Ответить | Правка | ^ к родителю #300 | Наверх | Cообщить модератору

	318. "Оптимизация кода компилятором может привести к появлению..."	+2 +/–
	Сообщение от Аноним (??) on 02-Ноя-13, 09:29
	> и что характерно — вовсе не за синтаксис. сюрприз, да? За синтаксис тоже можно: он ориентирован на загон дeбила в стойло. Пинками. Если кому-то насильно втюхивают как именно форматировать программу - это означает програмера считают попросту недееспособным, которого надо поместить в палату и закрыть на ключ, заэнфорсив конкретную модель поведения "для его же блага и блага окружающих".
	Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

	327. "Оптимизация кода компилятором может привести к появлению..."	+2 +/–
	Сообщение от arisu (ok) on 02-Ноя-13, 11:04
	синтаксис отстойный, конечно, я не спорю. но гвидобейсик не потому гвидобейсик. :3
	Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

	319. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от Аноним (??) on 02-Ноя-13, 09:52
	> популярность не обязательно коррелирует с удобством? Теоретически это может быть и так. Практически - по логике вещей получается что большинство страдает чем-то типа мазохизма. Довольно спорно, имхо. > да, на обероне написана ажно целая ось, с гуями. и на Active > Oberon тоже ось, и с весьма навёрнутыми гуями. просто оберон и > AO никто не популяризировал. Я что-то забыл: а кто популяризовывал си и хоть тот же линух, например? K&R где-то оплачивали рекламу? Или Торвальдс рисовал пингвина на эмпайр стейт билдинге, как некоторые 4-цветные? Ну или чем они так уж отличаются в этом плане? Скорее, обычный эффект - красивые и рафинированные академические конструкции оказываются не в кассу в реальном мире. Где надо временами просто привинтить вон тот швеллер болтами, профигачив дыры "по месту". А то что неэстетично и вообще adhoc - и черт с ним, работает же. Это главное. > да к тому же у них «синтаксис паскалевский, фи, отстoй!» Мне curly bracket синтакс больше нравится.
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	328. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 02-Ноя-13, 11:06
	> Теоретически это может быть и так. Практически - по логике вещей получается > что большинство страдает чем-то типа мазохизма. Довольно спорно, имхо. а чего спорного? ты точно описал реальное положение вещей. > Я что-то забыл: а кто популяризовывал си и хоть тот же линух не идиотничай, пожалуйста. ты же не я. > Мне curly bracket синтакс больше нравится. исключительно вопрос привычки.
	Ответить | Правка | ^ к родителю #319 | Наверх | Cообщить модератору

	199. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:37
	> Аноним такой «знаток», что не в силах отличить недостатки от достоинств? вот конктретно «неопределённое поведение при целочисленном переполнении» — это мегакосяк. подавляющее большинство процессоров при работе с целочисленой арифметикой ведут себя вполне определённо, и именно это поведение имело смысл стандартизировать. ну и ещё один мегакосяк — отсутствие возможности проверить, было ли переполнение в целочисленном арифметическом выражении. опять же: подавляющее большинство процессоров имеют для этого carry flag, и вполне имеет смысл дать стандартную возможность проверить, было ли переполнение, без предварительного «валидирования» всех операндов. но стандарты пишут идиоты^w сферические академики в вакууме. и у них выходит стандарт, у которого, на минуточку, есть понятие «поведение не определено». это, пардон, не стандарт, а кусок туалетной бумаги. поведение в стандарте *должно* быть определено. или определённый результат, или ошибка. а если оно «не определено» — это значит, что стандарт писали идиоты, больше заботящиеся об удобстве машины, а не человека.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	230. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 15:48
	> ведут себя вполне определённо, и именно это поведение имело смысл стандартизировать. Тем более что процы умеют выставлять carry-флаг в массе своей на уровне железа, блин...
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	235. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:04
	> но стандарты пишут идиoты^w сферические академики в вакууме. и у них выходит > стандарт, у которого, на минуточку, есть понятие «поведение не определено». > это, пардон, не стандарт, а кусок туалетной бумаги. поведение в стандарте > *должно* быть определено. или определённый результат, или ошибка. а если оно > «не определено» — это значит, что стандарт писали идиoты, больше заботящиеся > об удобстве машины, а не человека. Ваши рассуждения очень напоминают поттеринга: "наше любимое ядро linux поддерживает эту функциональность, а проблемы тех, у кого ядра не ее не поддерживают, нас не беспокоят". Если язык позиционируется как _портабельный_ - он должен опираться на общий доступный минимум возможностей _всех_ целевых платформ, а не "большинства".
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	253. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:48
	> Если язык позиционируется как _портабельный_ - он должен опираться на общий доступный > минимум возможностей _всех_ целевых платформ, а не «большинства». любую идею можно довести до абсурда — и тогда получится полная фигня. в данном случае «портабельность» не помеха стандартизации поведения при переполнении и добавления доступа к carry flag. именно потому, что *большинство* железа работает именно так. а остальные — пусть эмулируют. это сильно облегчило бы написание огромного количества кода и убрало бы кучу дурацких проверок, которые сейчас приходится делать из-за того, что «а вдруг у трёх с половиной инвалидов железо при переполнении вовсе взрывается? давайте объявим переполнение UB!» маленький пример тебе: некоторые архитектуры не поддерживают unaligned-доступ и могут читать только, например, слова, которые больше байтов. тем не менее компиляторы си на этих архитектурах поддерживают произвольный доступ к байтовым массивам, вставляя эмуляцию. если строго следовать твоим постулатам, то байтовые массивы из сей надо нафиг выкинуть, потому что у нас есть архитектуры, где они «нативно» не поддерживаются. глупо получается, правда? тем не менее, чётко по твоему предложению. кратко: если *большинство* процессоров уже кучу лет работают неким определённым образом, и это *настолько* привычно, что программисты подчас забывают об UB, полагаясь на такое поведение — то следует починить стандарт, прописав туда именно такое поведение. а остальные архитектуры пусть эмулируют. вообще, UB из стандарта надо выкинуть. потому что каждое документированое UB — это *ошибка* *в* *стандарте*. авторы тупо побоялись взять на себя ответственность и отделались отпиской «моя хата с краю, ничего не знаю». а это, как я уже говорил, не стандарт, а туалетная бумага.
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	307. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 01-Ноя-13, 19:07
	> кратко: если *большинство* процессоров уже кучу лет работают неким определённым образом, и это *настолько* привычно, что программисты подчас забывают об UB, полагаясь на такое поведение — то следует починить стандарт, прописав туда именно такое поведение. а остальные архитектуры пусть эмулируют. Ну вот поццеринг примерно так же и рассуждал. Кому надо - пусть эмулируют.
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	311. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Michael Shigorin (ok) on 01-Ноя-13, 23:44
	> Ну вот поццеринг примерно так же и рассуждал. Мягко говоря, некорректное сравнение -- поскольку передёрнули правило и исключение.
	Ответить | Правка | ^ к родителю #307 | Наверх | Cообщить модератору

	14. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:09
	> Это косяки ЯЗЫКА. > Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих. Могу посоветовать тебе и твоим функциональным аналогам писать на Visual Basic.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	36. "Оптимизация кода компилятором может привести к появлению про..."	–3 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:44
	>> Это косяки ЯЗЫКА. >> Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих. > Могу посоветовать тебе и твоим функциональным аналогам писать на Visual Basic. Советы свои знаешь куда засунь?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	98. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 16:25
	> Советы свои знаешь куда засунь? Да ладно. Барсик - это тайная эротическая мечта любого сишника)
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	156. "Оптимизация кода компилятором может привести к появлению про..."	+3 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 20:19
	> Да ладно. Барсик - это тайная эротическая мечта любого сишника) Вы явно путаете сишников и питонистов. Тут один типаж даже название ему придумал - гвидобэйсик.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	241. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-13, 16:14
	>> Да ладно. Барсик - это тайная эротическая мечта любого сишника) > Вы явно путаете сишников и питонистов. Тут один типаж даже название ему > придумал - гвидобэйсик. Ну так правильно. Питонисты имеют то, о чем сишники только мечтают.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	245. "Оптимизация кода компилятором может привести к появлению..."	+2 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:29
	> Ну так правильно. Питонисты имеют то, о чем сишники только мечтают. честно: не мечтаем мы о том, чтобы смена количества пробелов в начале строки изменяла поведение программы. а автоматическое управление памятью у нас и так есть, если надо.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	320. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 02-Ноя-13, 09:57
	> Ну так правильно. Питонисты имеют то, о чем сишники только мечтают. Тормозилово, с синтаксисом где дeбила пинками заставляют форматировать гoвнокод правильно? Боюсь, вы не очень понимаете о чем мечтают сишники. Эй, питонист, а запиши число 0x20 по адресу 0x100500. Ну допустим там memory-mapped периферия висит и это какой-то битовый флаг в каком-то регистре. Как, питон все еще кажется мечтой сишника? :)
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	26. "Оптимизация кода компилятором может привести к появлению про..."	+8 +/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 13:37
	> Это косяки ЯЗЫКА. > Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих. Стандарт определяет язык, который хорошо переносим и одновременно эффективен. Результат переполнения сильно зависит от аппаратной платформы, поэтому язык НЕ МОЖЕТ регламентировать результат переполнения. Если он регламентирует, к каждой операции с арифметикой указателей придётся генерировать код проверки переполнения и приведения результатов к заданному стандартом виду. Это убьёт эффективность. Косяка в этом никакого нет, очень логичная особенность дизайна, если понимать, что язык изначально позиционировался как переносимая альтернатива ассемблеру. Другой вопрос, что сейчас уже не очень естественно писать почти всё прикладное ПО на таком языке. Но традиция пока жива. :-)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	44. "Оптимизация кода компилятором может привести к появлению про..."	–3 +/–
	Сообщение от тоже Аноним (ok) on 30-Окт-13, 13:57
	Вообще-то "почти все прикладное ПО" пишут не на Сях, а скорее на Крестах. В которых есть Стандартная Библиотека, при правильном применении избавляющая от необходимости маяться с указателями вовсе. Си используются не в прикладном, а в системном ПО, драйверах и кодеках, где над бинарными данными может вообще не быть никакой абстракции и где действительно нужно иметь ничем не ограниченный доступ к памяти.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	47. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 14:12
	> Вообще-то "почти все прикладное ПО" пишут не на Сях, а скорее на > Крестах. К сожалению, в крестах наследие Си очень сильно. В теории -- да, стандартная библиотека и всё такое. А на практике... Для начала половина пользователей пишет на нём так, как будто это Си с дополнительными фичами. Я не уверен, что при переходе от Си к "Крестам" ошибок стало меньше, вот в чём беда.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	52. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от тоже Аноним (ok) on 30-Окт-13, 14:17
	Это скорее legacy-проблемы. За последнее время по всему интернету развешаны статьи-предупреждения "Не пользуйтесь Сями в Крестах, есть смарт-пойнтеры и контейнеры, которых вам хватит за глаза! А если не хватает, почитайте внимательно документацию к STL".
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	57. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 14:30
	> Это скорее legacy-проблемы. За последнее время по всему интернету развешаны статьи-предупреждения > "Не пользуйтесь Сями в Крестах, есть смарт-пойнтеры и контейнеры, которых вам > хватит за глаза! А если не хватает, почитайте внимательно документацию к > STL". Это-то да. Но ведь оно же лет без малого пятнадцать так. Некоторые сдвиги есть, но большинство кода откроешь -- прослезишься, те же самые родные поделия типа примеров из статьи. Причём иногда осмысленные, но чаще не очень (то есть всё можно было сделать именно на плюсах, а не на си с крестами).
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	58. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от тоже Аноним (ok) on 30-Окт-13, 14:32
	Потому что проблема не столько в легаси-коде, сколько в легаси-учебниках ;)
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	66. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 14:47
	Ну да, разруха не в клозетах. Она в головах. :-D Но я всё равно в последние несколько лет не люблю использовать C++ там, где удаётся не использовать.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	79. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от ананим on 30-Окт-13, 15:12
	Потому что не уверены в своих силах? Я предпочитаю рассчитывать на себя больше, чем на дядю. Свои ошибки легко правятся (благо вот ещё один анализатор есть, см. сабж) Новости про уязвимости в жаба, дотнет,.. да любом — вот где любовЪ и слёзы. И когда выйдут исправление — полное и безоговорочное х/з. С другой стороны стл железобетонный. Буст чуть менее. А что ещё надо?
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	81. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 15:23
	> Потому что не уверены в своих силах? Нет, не поэтому. Не хочу.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	86. "Оптимизация кода компилятором может привести к появлению про..."	–5 +/–
	Сообщение от ананим on 30-Окт-13, 15:40
	Да я и так понял. Порассуждать с надутыми щёками мы все горазды. Типа, ох уж эти быдлoкoдеры… это они, гады… не мы. не, точно не мы. Мы на вот этой <панацее> не_быдлoкoдим… Но если вдруг случайно получается, то блингейс, лари, стиви (и тд) виноваты… в следующем квартале говорят исправят. А как же… В любой курилке такое обсуждается… в застенках ынтырпрайза… между одноэсниками, дотнетчиками, ораклистами и тд
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	105. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 17:01
	О, да-да, мнение опеннетовского анонима сейчас перевернёт мою вселенную. Впрочем, хотите самоутверждаться -- самоутверждайтесь, мне-то какое дело?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	129. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 18:01
	Ну-ну, просветите меня про состав стандартной библиотеки и расскажите, как жить. Я писал на этом языке, когда вы, дорогой мой, пешком под стол ходили и в комментариях специалиста вашего уровня, простите, не нуждаюсь.
	Ответить | Правка | ^ к родителю #317 | Наверх | Cообщить модератору

	124. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 17:45
	> Но я всё равно в последние несколько лет не люблю использовать C++ там, где удаётся не использовать. Аналогично. Для системного/встроенного программирования использую Си, а С++ в этих областях считаю, в общем-то, злом. Для прикладного - Паскаль-подобные языки "быстрой разработки". Они здесь тоже более эффективны, чем С++.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	165. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от тоже Аноним (ok) on 30-Окт-13, 21:13
	Ну, а мне, например, нужно разрабатывать программы, которыми люди потом пользуются весь рабочий день не один год. Быстрота разработки здесь на втором плане, аккуратность и отзывчивость программы - на первом.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	200. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:40
	> Для начала половина > пользователей пишет на нём так, как будто это Си с дополнительными > фичами. единственный нормальный способ использовать плюсовое недоразумение.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	224. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от ананим on 31-Окт-13, 15:39
	Бред. Нормальное плюсовое использование — это шаблоны. Вот это действительно мощь и красота языка. С другой стороны можно использовать на уровне тех же делфей. Как пример Qt, по уровню вхождения, сложности и стройности один в один практически. Главное не злоупотреблять различными техниками в перемежку. В общем для юзер-спейса лучше ещё никто ничего не придумал.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	228. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 15:44
	> Бред. Нормальное плюсовое использование — это шаблоны. > Вот это действительно мощь и красота языка. это мощь и красота костылей. ещё и на уровне синтаксиса костыльных. вообще, настолько увечно добавить увечный turing-complete язык с целью сделать генерики — это надо быть сильно упоротыми. ну, или авторами c++, что одно и то же, кажется.
	Ответить | Правка | ^ к родителю #224 | Наверх | Cообщить модератору

	252. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от ананим on 31-Окт-13, 16:46
	Ха! Шаблоны существовали уже тогда, когда маркетолухи ещё и слово то такое, генерики, не придумали. Да и сами генерики — облегённый вариант шаблонов для умственно-отсталых.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	329. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от Vkni (ok) on 02-Ноя-13, 20:47
	Я, честно говоря, тоже в своё время восхищался шаблонами, пока не узнал, что вывод типов появился в 1969-м и переоткрыт в 1978-м. Поэтому можно было сделать всё значительно красивее и приятнее.
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	330. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 02-Ноя-13, 21:17
	> Ха! Шаблоны существовали уже тогда, когда маркетолухи ещё и слово то такое, > генерики, не придумали. угу-угу. правда, в Аде их придумали в районе 1978-го года, а первый cfront ни о каких шаблонах не знал, AFAIR. но если факты мешают фанбоям — то тем хуже для фактов.
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	16. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 13:14
	> Если в стандарте языка указано, что результат операции переполнения не определен, то нет ничего криминального в том, что компиляторы этим пользуются. верно.. какого чёрта -- программист такой "умный" что уже ПОСЛЕ того как СОВЕРШИТ переполнение проверяет "а не случилось ли переполнение?".. всё правильно думает компилятор -- "программист уже совершил сложение, значит программист уверен в том что переполнения невозможно, а следовательно я выкину лишние проверки...". нет чтобы проверить каждое из гипотетических слогаемых -- ПЕРЕД всякими операциями.. #include <climits> ... ... if (buf >= INT_MAX/2 || len >= INT_MAX/2) {     return; // overflow } ... ...
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	18. "Оптимизация кода компилятором может привести к появлению про..."	+4 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:23
	> buf >= INT_MAX/2 || len >= INT_MAX/2 По-моему, это еще более страшный быдлoкод.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	21. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 13:28
	>> buf >= INT_MAX/2 || len >= INT_MAX/2 > По-моему, это еще более страшный быдлoкод. где ты тут код увидил? тут лишь одно выражение, которое проверяет что каждое из слагаемых меньше чем половина от максимального значения обычного целочесленного типа..
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	29. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:40
	> где ты тут код увидил? тут лишь одно выражение, которое проверяет что > каждое из слагаемых меньше чем половина от максимального значения обычного целочесленного > типа.. Да-да, скажи ещё что кот по клавиатуре прошёл и оно само напечаталось. Ты показал чудовищную некомпетентность, что, впрочем, вполне ожидаемо, ибо ты её показываешь в каждом посте. Плюс хамская манера общения и неадекватная реакция на критику, догадки о твоём возрасте в очередной раз подтвердились.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	31. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:41
	> Плюс хамская манера общения Хамская манера общения тут только у тебя (хотя я и использовал слово "быдлoкод" парой сообщений выше).
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	37. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:45
	> Хамская манера общения тут только у тебя (хотя я и использовал слово > "быдлoкод" парой сообщений выше). Залогинься, Xasd. Щас прям, поверю что пришёл компетентный Аноним тебя защищать.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	50. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 14:15
	Ну ты же знаешь, что комент про быдлoкод писал не ты? :)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	20. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:25
	За такой код надо тебе по пальцам молотком для мяса пройтись.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	23. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 13:28
	> За такой код надо тебе по пальцам молотком для мяса пройтись. ну напиши как надо. балобол. так как ты писать ни чего не будешь -- то разговор я думаю на этом будет закрыт. > молотком для мяса тоже мне, любитель мяса.. жиром заплыл весь.. гуру элегантного кода на сиплюсплюс.. тфу, блин..
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	25. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:35
	Лол, как тебя зацепило. Нет уж - давай ты свои ошибки сам исправишь. Подскажу: во-первых, buf это указатель, а указатель с INT ничего общего не имеет. Во-вторых, указатель может располагаться в любой половине адресного пространства (в userspace будет в одной, в ядре - в другой), так что в одном случае твой код гарантированно не будет работать.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Оптимизация кода компилятором может привести к появлению про..."	–4 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 13:43
	> buf это указатель да -- я привёл код который просто проверяет переполнение при сложении. совершенно нет смысла это использовать для случая с указателями. (и вообще я считаю что нет смысла складывать указатели и работать с указателями -- как с целыми числами) вот именно в этом смысле я принимаю критику.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	41. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:49
	Оправдываться уже поздно, молодой человек. С вами всё понятно.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	45. "Оптимизация кода компилятором может привести к появлению про..."	–3 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 13:57
	> Оправдываться уже поздно, молодой человек. С вами всё понятно. ну слово не воробей. если уж я написал свою точку зрения -- назад взять слова не могу :-) .. да -- я считаю что работать с указателями как с числами -- это плохо. и что это источник ошибок.. что уж тут теперь :-) -- что есть то есть
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	177. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 22:32
	> да -- я считаю что работать с указателями как с числами -- > это плохо. и что это источник ошибок.. Это совершенно нормально. По другому запускать код находящийся в known локации или парсить структуры в новой локации иначе было бы зело геморно. Не менее геморно было бы работать с mmaped устройсвами и прочая.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	69. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ананим on 30-Окт-13, 14:51
	>Лол, как тебя зацепило. Именно что ЛОЛ. Обозвал человека, докажи что заслуженно. А пока только эти эпитеты — xам и провокация флэйма. зыж 2Xasd: 1.|| не подходит вообще, т.к. по стандарту (даже без оптимизации) если значения первого операнда достаточно, чтобы определить результат операции, то второй операнд не вычисляется. Вот с && другая история. 2. ситуация, когда указатель чуть меньше INT_MAX(? понятно, что в контексте имеется ввиду максимальное значение для указателя, см. ниже), а длина маленькая (или наоборот) вполне валидны. 3.$ cat 111.c #include <stdio.h> main() {     printf("pointer - %li\nunsigned int - %li\nint - %li\nchar - %li\nlong - %li\n",     sizeof(char *),sizeof(unsigned int),sizeof(int),sizeof(char),sizeof(long)); } $ gcc 111.c $ ./a.out pointer - 8 unsigned int - 4 int - 4 char - 1 long - 8 (логично, что на 64-битной платформе указатель равен 64 бита, не так ли?) 4. Очевидно вычитание вам поможет. Примерно так (ULONG_MAX - buf) > len, т.к. это условие должно выполнятся.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	78. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 15:10
	да да, разумеется ``(ULONG_MAX - buf) > len`` здесь конечно явно уместнее) .. говоря про указатели -- точно уж не то что я привёл выше :-D кстате мы тут исходим из того что размер size_t и long -- одинаковые... ведь не существует константы SIZE_T_MAX .. верно?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	83. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ананим on 30-Окт-13, 15:33
	$ cat 222.c #include <stdio.h> main() {     size_t l = ~0; // можно с модификаторами, тоже работает size_t l = ~0ull;     printf ("%lx\n", l); } $ gcc 222.c $ ./a.out ffffffffffffffff > ведь не существует константы SIZE_T_MAX .. верно? ну… оно менятся от платформе к платформе, но… имеется :D <stdint.h> /* Limit of `size_t' type.  */ # if __WORDSIZE == 64 #  define SIZE_MAX              (18446744073709551615UL) # else #  define SIZE_MAX              (4294967295U) # endif
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	91. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от pavlinux (ok) on 30-Окт-13, 16:01
	> /* Limit of `size_t' type.  */ Так не интересно, это читерство. :-P
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	95. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ананим on 30-Окт-13, 16:07
	Кстати согласен. Такие вещи должны определятся на целевой платформе... но константа не требует вычислений! :D Зыж А хреневознает, может этот файл генерится при установке? ;)
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	173. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от pavlinux (ok) on 30-Окт-13, 22:17
	> А хреневознает, может этот файл генерится при установке? ;) Какой, <stdint.h> ?  Не, он феншуйный - ISO/IEEE ля-ля-ля:1999
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	89. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от pavlinux (ok) on 30-Окт-13, 15:57
	> ведь не существует константы SIZE_T_MAX .. верно? #define SIZE_T_MAX  ((2UL << (sizeof(size_t) * 8) - 1) - 1) как вариант #define SIZE_T_MAX  ((2UL << __WORDSIZE - 1) - 1) #define SIZE_T_MAX  ((2UL << __BITS_PER_LONG - 1) - 1) // эта круче, звучит красиво : 2уль вжить-вжить битсперлонг :)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	30. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 13:40
	> слогаемых По русскому у тебя то-же что и по информатике?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	39. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Xasd (ok) on 30-Окт-13, 13:47
	>> слогаемых > По русскому у тебя то-же что и по информатике? нет, по русскому у меня была почти двойка. а почему спрашиваешь? может про физкультуру ещё интересно узнать? :-) по физкультуре было обычно 4
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	46. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от тоже Аноним (ok) on 30-Окт-13, 14:03
	А информатики еще не было вовсе, мы поняли. Бросьте позориться. Вы написали безграмотное программистское решение с безграмотными русскими комментариями, да еще и раздуваете личностный срач. Увы, "никогда не выдается второго случая создать первое впечатление".
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	49. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 14:12
	> А информатики еще не было вовсе, мы поняли. была. у нас даже были там в классе -- немножко компьютеров :) .. но при чём тут вообще школа-то? > Бросьте позориться. Вы написали безграмотное программистское решение с безграмотными > русскими комментариями, безграмотное -- только лишь для случая с указателями. однако как выше я уже писал -- я не вижу вообще смысла работать с указателями как с числами. > да еще и раздуваете личностный срач. ну тыг возьми да и поудаляй его! ой.. я забыл -- ты ведь всего-лишь аноним, без каких-либо прав :-D .. > Увы, "никогда не выдается второго случая создать первое впечатление". проблема века :-D ну давай, пиши ещё.. опазорь как-нибудь меня совсем уж! всем же так интересно :-) ...все бросили свою работу, и бегом бегут на ОпенНет читать как один аноним троллит другого анонима... :-)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	55. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от тоже Аноним (ok) on 30-Окт-13, 14:22
	То, что вы невнимательны, было заметно и до этого комментария. Работать с числами, большими половины максимума, вы тоже не видите смысла?
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	60. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от Xasd (ok) on 30-Окт-13, 14:40
	> Работать с числами, большими половины максимума, вы тоже не видите смысла? да, конечно. а в некоторых случаях -- я даже не вижу смысла работать с числами которые превышают четвердь от максимума :) ..и так далее... я вообще не люблю числа, которые граничат со своими "возможностями".. не люблю граничные значения.. > То, что вы невнимательны, было заметно и до этого комментария. хорошо.. я буду стараться быть повнимательнее :)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	168. "Оптимизация кода компилятором может привести к появлению про..."	+4 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 21:33
	> четвердь Очень жаль что тебе не вкатили двойку в "четверди" по русскому языку. Ты этого не только заслуживаешь, но и взялся бы немного за ум. А так получился папуас, который даже немного претендует на то что умеет погонщиком слонов быть.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	331. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Xasd (ok) on 03-Ноя-13, 00:50
	> Очень жаль что тебе не вкатили двойку в "четверди" по русскому языку. с чего ты взял что такого не случалось? как раз такое бывало :-) .. всё равно не понимаю почему моя школьная биография так интересна. обычная школьная биография
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	332. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 03-Ноя-13, 01:54
	> с чего ты взял что такого не случалось? > как раз такое бывало :-) .. причём постоянно, судя по твоим текстам.
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	334. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Led (ok) on 03-Ноя-13, 03:53
	>> Очень жаль что тебе не вкатили двойку в "четверди" по русскому языку. > с чего ты взял что такого не случалось? > как раз такое бывало :-) .. И ещё будет
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	202. "Оптимизация кода компилятором может привести к появлению..."	–2 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:49
	> опазорь как-нибудь меня совсем уж! зачем трудиться, если ты сам отлично справляешься с задачей «опазоривания»? главное — дать тебе возможность писать, и ты сам себя так обгадишь… мы всем опеннетом за месяц не сможем повторить.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	77. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от ... on 30-Окт-13, 15:03
	Подобные проверки перед каждой арифметической операцией негативно повлияют как на производительность так и на читаемость кода. Да и писать такой код, держа в голове кто unsigned, кто long, а кто вообще double и какую проверку в связи с этим нужно влепить, - не особо комфортно.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	99. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от ананим on 30-Окт-13, 16:25
	А для этого есть венгерская нотация и тд. Опять же, имеет смысл для глобальных (или в нэймспейсах) переменных. Для локальных переменных избяточно.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	203. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:56
	> А для этого есть венгерская нотация за такое применение венгерской нотации надо бить бамбуковой палкой по пяткам, отбирать клавиатуру и вручать метлу. использовать венгерскую нотацию следует для логических групп, а не для костыльного обозначения типов. cntItems — нормально, если в проекте принято, что «cnt» — это префикс для обозначения счётчика. dwItemCount — ненормально, что бы там в проекте ни принимали. привет, проблемы с портируемостью, например: «по средам и субботам dw обозначает два байта, по четвергам — четыре, а в пятницу бывает восемь, если это чётный день года.»
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	214. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от ананим on 31-Окт-13, 13:06
	>например: «по средам и субботам dw обозначает а не нужно выдумывать левые обозначения для стандартных типов. int тоже меняется, но если переменная имеет тип int, то она имеет (или он её) постфактум. либо определяйте этот тип также, либо не используйте такие обозначения. а то ваша венгерская нотация получается с явно выраженным албанским акцентом. зыж и вот как раз за такое точно нужно и палочками по мягкому месту, и в угол.
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	201. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:46
	> какого чёрта — программист такой «умный» что уже ПОСЛЕ того как СОВЕРШИТ > переполнение проверяет «а не случилось ли переполнение?».. прикинь, процессор тоже делает именно так. сюрпрайз, да? а то, что си заставляет вместо элегантной проверки на установленый carry flag постфактум городить портянки типа вышеприведённой — это недостаток стандарта. кстати: а нагороди-ка такую портянку на выражение типа такого: 'a+(b*c)/d-e+f*g', а? ну да, ну да: у нас же машины правят миром, поэтому работу, которую может выполнить машина, на самом деле должен выполнять человек: городить кучу дурацких ручных проверок, разбивая выражение на куски (представим, кстати, что в этом выражении некоторые члены — не переменные, а вызовы функций). при том, что процессор заботливо устанавливает флажок переноса, позволяющий обойтись чем-то вроде 'guard_carry(expr) { fail-processing-code }'. тьфу.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	321. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 10:04
	> прикинь, процессор тоже делает именно так. сюрпрайз, да? Ну там проблема в том что на ширину регистров завязано, тогда как целочисленные типы совсем не обязаны 1 в 1 укладываться в регистры. Другое дело что все-равно же математику на регистрах "не той" ширины делают, а тут в половине случаев еще и железом подпереть можно было.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

9. "Оптимизация кода компилятором может привести к появлению про..."	+7 +/–
Сообщение от Аноним (??) on 30-Окт-13, 12:36
вообще забавно: сначала обратиться к структуре по указателю (*sk = tun->sk), а уже затем проверить указатель на NULL
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Оптимизация кода компилятором может привести к появлению про..."	+3 +/–
	Сообщение от Crazy Alex (ok) on 30-Окт-13, 13:39
	Да уж, возмущаться таким кодом - умильно. С первым примером, конечно, надо ворнинги бы выдавать или статикой проверять, но косяком компилятора это я бы не называл. Тем более, что проблема широко известна, как и решение -  "if (buf_end > buf && buf_end - buf > len)". Допустим, в писании бинарного поиска практически всегда обращают внимание на то, то надо не (a+b)/2 писать, а (a-b)/2 - именно из-за возможного переполнения.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	56. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 14:26
	Зачем так сложно? :) Вот то, что имели ввиду авторы, но не осилили реализовать:         if ((intptr_t)buf + len < buf)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	100. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 16:27
	> if ((intptr_t)buf + len < buf) И что, компилятор это не выкинет?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	111. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 17:12
	Проверьте :)
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	106. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Crazy Alex (ok) on 30-Окт-13, 17:04
	Или так, но это optional тип.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	113. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 17:15
	Что значит optional? Это стандартный тип, начиная с С99.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	116. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Crazy Alex (ok) on 30-Окт-13, 17:29
	n1124.pdf 7.18.1.4 ...These types are optional
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	125. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 17:46
	Да, действительно.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	204. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 08:57
	> Зачем так сложно? :) Вот то, что имели ввиду авторы, но не > осилили реализовать: if ((intptr_t)buf + len < buf) беда в том, что значение этого выражения всё равно не определено, если случилось переполнение. так что этот код точно такой же бессмысленный, как и код из новости.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

22. "Оптимизация кода компилятором может привести к появлению про..."	+9 +/–
Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 13:28
Строго говоря, код в примерах не очень корректный. Увы, подобные перлы действительно перестают работать в результате деятельности оптимизатора, но это проблема кода, а не оптимизатора. Полукорректная проверка переполнения при арифметике с указателями. Да, проверка переполнения, конечно, хорошая вещь, но ТАК это не надо делать. Поведение этого кода при переполнении неизвестно. Соответственно, это код под одну конкретную платформу, включая в понятие платформы и компилятор. Под то окружение, где работает так, как рассчитывал автор кода. И вполне естественно, что с развитием компилятора и появлением в нём более серьёзных оптимизаций ситуация изменилась. Код перестал работать так, как работал. Увы и ах. Ну так просто писать это надо подумавши. Посчитать, например, длину буфера вычитанием указателей и проверить, что индекс в диапазоне. А не заниматься не переносимым сложением с расчётом на переполнение, результат которого неопределён. Ну и в переводе ошибка. Это не tun->sk не может быть нулевым, это tun не может быть нулевым. Кстати, в этом примере трудно не согласиться с оптимизатором! Если строкой выше идёт доступ к члену структуры, то указатель просто не имеет права быть нулевым. Проверять надо до доступа. Глючный код -- неопределённый результат, в чём удивление? Тот, кто этот код писал, видел за кодом арифметику с указателями  на уровне ассемблерных команд. Это ценное умение. Но одновременно -- отвратительная привычка, если сопровождается тем, что программист рассчитывает на определённую низкоуровневую реализацию. Так он просто не сможет писать переносимый код. Рациональное зерно, правда, в том, что кривоватый код, который ранее работал безупречно, может перестать это делать с включением оптимизации или заменой версии компилятора. Но ведь это ожидаемо и очевидно, нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

	61. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 14:40
	> А что, в С разыменование указателя не сопровождается проверкой на NULL? Еще чего не хватало.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	62. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 14:41
	Вы про нулевой указатель и tun->sk? Да, там прибавление смещения. Но ведь даже прибавлять к нулевому указателю что-либо по стандарту, ЕМНИП, нельзя. И, кстати, что бинарно представляет собой этот нулевой указатель, иди разбери -- где как. Чтение чего-то по небольшому смещению -- вопрос, к чему приведёт, зависит от железки и ОС сильно. На свете полно платформ, где это просто тихо сработает, прочитав мусор. И полно таких, где нет. Кстати, указатель -- не всегда только смещение. Сейчас все привыкли в прикладных приложениях к тому, что мир плоский (неважно, 32 или 64 бита), а вообще-то часто есть ещё и сегмент. Во времена 8086/8088 повсеместно было иначе. Разные указатели, разные "модели памяти" для программ... В общем, не в любом случае это даст сегфолт. Не говоря уже о том, что раньше оптимизатор мог работать иначе и тихо вырезать эту операцию вообще, но не считать её признаком, что указатель tun -- ненулевой. И, как следствие, не удалить проверку на ноль. Или переставить чтение и проверку. Он много чего мог. И да, ПРОВЕРКОЙ разыменование не сопровождается. Это противоречило бы всему дизайну языка.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	67. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 14:49
	> И, кстати, что бинарно представляет собой этот нулевой указатель, иди разбери -- где как. На любой вменяемой платформе это 0.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	76. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 15:01
	> На любой вменяемой платформе это 0. Э, не спешите. Если в плоской модели, то наверное. Я другого ещё не видел, во всяком случае. Хотя никто этого не обещает, наверное, так будет. А вот если указатель включает в себя селектор сегмента и смещение, то каким будет этот селектор -- иди разбери. Возможно, каким-то таким, чтобы любая операция падала, не факт, что нулевым. Но это отдаётся на откуп железке-ОС-компилятору.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

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

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

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

	206. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 09:03
	> Вообще-то, на любой платформе это 0. Внутреннее представление значения не имеет. http://c-faq.com/null/ptrtest.html тут нюанс: NULL — это всегда 0, и всегда обозначает «негодный указатель». но обратное неверно: «негодный указатель» может и не быть NULL'ом (например, указывать на область памяти, которой нет).
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

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

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

	74. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 14:58
	Нет, всё не так. :-) Очень много где будет защита и от чтения. Стандарт такую практику, конечно, запрещает. Вернее, он ничего не запрещает, но честно говорит, что результат вам может не понравиться. Это и есть "результат неопределён", к слову. :-) Результат неопределён = "это в разных реализациях может быть сделано по-разному, не рассчитывайте ни на что".
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

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

	127. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 17:56
	Такая запись, возможно, не вызовет исключения, но это не значит, что она будет корректной :) В бытность МС-ДОСа, помнится, в борландовских рантаймах в начале сегмента данных была специальная область с контрольной суммой, которая пересчитывалась на выходе, и если ты писал что-то по нулевому указателю, тебе на выходе на консоль выдавалось предупреждение :)
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

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

	151. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 20:05
	> На AVR по нулевому адресу находится регистр R0. Читать/писать его таким образом > абсолютно корректно. AVR вообще гарвардец, по поводу чего у него несколько адресных пространств в самом явном виде. Флеш у него для кода (данные могут быть только константой и возвращаются оттуда весьма отдельным приседанием). А оператива - только для данных (и напрочь не может содержать код, что добавляет головняка в некторых случаях).
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

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

	169. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 21:45
	> Угу, гаврвардец. Но ещё у него регистры спроецированы в адресное пространство. Что, > в сущности, очень удобно иногда. Да, иногда это удобно :). Был тут один проц - ему переполнение буфера перезаписывало образ регистров в RAM. Это было весьма необычно. Правда, тот был неймановец. > по нему и ругаться на это прямо в компиляторе. Если в си позапрещать все потенциально опасные опции - как на нем тогда писать системные приблуды?
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	198. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от тоже Аноним (ok) on 31-Окт-13, 08:35
	> Если в си позапрещать все потенциально опасные опции - как на нем тогда писать системные приблуды? Два способа навскидку: ассемблерные вставки и какое-нибудь PRAGMA_I_KNOW_WHAT_I_DO - намек компилятору, что дальнейший код выше его понимания ;)
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

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

	322. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 10:17
	> «негодный указатель». всё. точка. негодный. Дяденьки, идите нафиг. На сях можно и как-то так: void* entry = (void *) 0x0; int main() { goto *entry; } На это gcc даже warning не выдает. На писюке это конечно свалится по сегфолту, т.к. нету там никакого кода в 0x0, и вообще. А на половине микроконтроллеров по этому адресу будут вполне себе первые инструкции выполняемые после включения и это будет что-то типа ребута (не совсем идентичного аппаратному, но обычно это не принципиально). Если на системном языке так будет нельзя - какой же он системный? :)
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

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

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

	205. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 09:00
	> А что, в С разыменование указателя не сопровождается проверкой на NULL? нет. этого делать нельзя, но по рукам никто не ударит, и код проверки тоже не вставят. точнее, по стандарту — не обязаны вставлять, это может быть дополнительной опцией компилятора. а может и не быть. > разве эта строчка при исполнении не должна вызвать сегфолт в любом случае? нет. более того, и не везде вызовет. в m$-dos, например, не вызовет. или в системе, где нет MMU и аппаратной защиты страниц.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

24. "Оптимизация кода компилятором может привести к появлению про..."	+5 +/–
Сообщение от Tav (ok) on 30-Окт-13, 13:32
В приведенных примерах компилятор следует стандарту, а программист предполагает определенное поведение в случаях, для которых оно не определено. Это не проблема компилятора.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Филипп Филиппович (ok) on 30-Окт-13, 13:39
	> В приведенных примерах компилятор следует стандарту, а программист предполагает определенное > поведение в случаях, для которых оно не определено. Это не проблема > компилятора. Именно так. Но, возможно, проблема пользователя, который получил некорретно работающий код там, где раньше был корректный, просто обновлением версии компилятора. А так -- да, кривой код -- кривой результат.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

40. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
Сообщение от commiethebeastie (ok) on 30-Окт-13, 13:49
-ffast-math годный дырооптимизатор.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
Сообщение от Андерй on 30-Окт-13, 13:54
Интересно, какие ошибки компилятора нужны АНБ, что используется именно определённая старая версия для TrueCrypt?...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

54. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
Сообщение от dq0s4y71 (ok) on 30-Окт-13, 14:19
Как здесь справедливо заметили, это - косяки программистов. В первом примере, если вы ожидаете переполнения (т.е. перехода в область отрицательных значений), то вы должны и проверять его КОРРЕКТНО, т.е.:         if ((intptr_t)buf + len < buf) Этот код работает как надо при любой оптимизации, можете проверить. Второй пример вообще странный. Если tun == NULL, то ваша программа упадёт ещё до того, как она достигнет оптимизируемого участка. Обвинять оптимизацию в том, что она неправильно компилит и без того кривую программу - это, конечно, сильно...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	123. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 17:40
	> if ((intptr_t)buf + len < buf) Если len объявлена беззнаковым числом, то buf+len<buf ложно при любых значениях buf и len и проверка может быть сочтена избыточной. Второй пример "упадёт" только если адрес 0000:0000 недоступен для чтения. Во многих ОС это так, но считать это аксиомой и закладывать в стандарты ЯП или в компилятор нельзя. Да, логичнее было бы изменить порядок следования операторов, но только это не делает код однозначно неправильным. Для сравнения: "c=a+b; if(!a)return;"
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	132. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от dq0s4y71 (ok) on 30-Окт-13, 18:23
	> Если len объявлена беззнаковым числом, то buf+len<buf ложно при любых значениях buf > и len и проверка может быть сочтена избыточной. Почему это? Сравниваются ведь указатели, а не целые, поэтому целое будут преобразовано в указатель, а не наоборот. > Для сравнения: "c=a+b; if(!a)return;" Не совсем корректное сравнение. У этого кода нет побочных эффектов, в отличие от. Я бы предложил такое сравнение:    (*funcptr)();    if (!funcptr) ... Тоже "корректно", но результат в большинстве случаев будет неожиданным :)
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	137. "Оптимизация кода компилятором может привести к появлению про..."	–2 +/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 18:43
	Почему это? Сравниваются ведь указатели, а не целые, поэтому целое будут преобразовано в указатель, а не наоборот. buf + len >= buf. Всегда для беззнакового len. Согласны? Преобразование типа данных - фиктивная процедура, предназначенная для контроля типов на уровне ЯП, которая не попадает (за редкими исключениями, напр. числа с плавающей точкой хранятся в FPU, а целые числа в регистрах общего назначения) в бинарный код. > Не совсем корректное сравнение Сравнение корректно в том плане, что в обоих случаях можно изменить порядок следования операторов, но нельзя убирать условие.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	143. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Ordu (ok) on 30-Окт-13, 19:06
	> buf + len >= buf. Всегда для беззнакового len. Согласны? Нет. Пример для 32-х битной платформы: buf=(void*) 0xffffffff; len=1
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	144. "Оптимизация кода компилятором может привести к появлению про..."	+3 +/–
	Сообщение от ананим on 30-Окт-13, 19:06
	Проводить сравнение методом «а давайте попробуем вызвать переполнение?» — идиoтизм. Вы ещ на ноль делите, чтобы проверить, был там 0 или нет. Вот корректная проверка (ULONG_MAX - buf) > len. И оптимизатор тоже идиoтизмoм её не посчитает. (или SIZE_MAX для size_t, или >= вместо >. Тут уж хозяин барин)
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	150. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 19:55
	> buf + len >= buf. Всегда для беззнакового len. Согласны? Вот ты и показал что ты болванчик. Как ты думаешь, что будет если к 32-битному uint32 0xfffffffe прибавить uint32 0x3? Ничего что оно врапнется по 32-битной границе? В общем твоими программами я бы пользоваться не стал - ты самых основ программирования не знаешь.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

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

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

	170. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 30-Окт-13, 22:08
	> Так думает не он, разработчики компиляторов. На самом деле все проще: математика у процов так работает.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	208. "Оптимизация кода компилятором может привести к появлению..."	+4 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 09:09
	>>> buf + len >= buf. Всегда для беззнакового len. Согласны? >> Вот ты и показал что ты болванчик. Как ты думаешь, > Так думает не он, разработчики компиляторов. нет. разработчики компиляторов следуют стандарту, в котором сказано, что переполнения на свете не бывает вовсе. соответственно, коспилятор вправе считать именно так и оптимизировать, основываясь на этом. пояснение: «неопределённое поведение» — это значит, что программист должен вручную позаботиться о том, чтобы переполнения не случилось; т.е. его не бывает в корректной программе. корректная же работа оптимизатора гарантирована только на корректных программах, на некорректных он может выдавать что угодно.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

63. "Оптимизация кода компилятором может привести к появлению про..."	+4 +/–
Сообщение от annulen (ok) on 30-Окт-13, 14:45
Оптимизации компилятора не нарушают стандарт языка, так что достаточно не писать код с undefined behavior, или выявлять его с помощью инструментов, таких как UB sanitizer в Clang.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

68. "Оптимизация кода компилятором может привести к появлению про..."	–4 +/–
Сообщение от iZEN (ok) on 30-Окт-13, 14:50
Доигрались. Вот так.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	73. "Оптимизация кода компилятором может привести к появлению про..."	+2 +/–
	Сообщение от ананим on 30-Окт-13, 14:58
	До чего? Что быдлo-кoд также ещё и быдлo-oптимизируется? Так это и без этой рекламы синтаксического анализатора было ясно. зыж Видимо истории со Сноуденом заставили активизироваться производителей анализаторов. Что сабж, что на хабре,… Типа — Вы ещё не проверяете код на безопасность самым лучшим (понятно каким?) анализатором? Тогда мы идём к вам.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	148. "Оптимизация кода компилятором может привести к появлению про..."	+4 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 19:47
	Жду когда изя перепишет фряшечку на яву :).
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

84. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
Сообщение от Пиу (ok) on 30-Окт-13, 15:36
новость - боян и фигня. уже много лет говорят про UB и что нужно его избегать. было бы куда интереснее, если бы они взяли настоящие баги компиляторов (а их много) и нашли те, которые бы приводили бы к проблема безопастности приложений. а так - это курсовая второкурсника на факультете информационной безопастности
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

90. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
Сообщение от Аноним (??) on 30-Окт-13, 15:59
Главное, что они написали анализатор, который тычет программистов в их косяки. А, по-хорошему, этим должен бы заниматься компилятор. Тот же Clang гордиться своими многословными отчётами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	110. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 30-Окт-13, 17:10
	Вот как раз компилятор этого делать и не должен. Он должен запускаться один раз и тупо собирать код согласно стандарту. А анализаторам место в ide, в коммит-хуках, системах ревью и так далее - в общем, там, где производится проверка качества кода. Сейчас в clang запихнули то, что должно быть в lint - ну так кто-то забыл о one responcbility principle (оно же кусок unix way, кстати) - бывает.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	160. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от NoName on 30-Окт-13, 20:54
	SRP вообщето...
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	163. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Crazy Alex (ok) on 30-Окт-13, 21:05
	Ну да, с аббревиатурами я не в ладах - в голове оно всё же не словами хранится. Сорри.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	306. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Аноним (??) on 01-Ноя-13, 19:03
	> Вот как раз компилятор этого делать и не должен. Он должен запускаться > один раз и тупо собирать код согласно стандарту. Ага. И так как про сообщения об ошибках компиляции в стандарте ничего не сказано, компилятор должен тупо игнорировать все ошибки.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	310. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от annulen (ok) on 01-Ноя-13, 21:43
	> Вот как раз компилятор этого делать и не должен. Он должен запускаться > один раз и тупо собирать код согласно стандарту. Собственно, clang это и делает, если не просить о большем. > А анализаторам место в ide, в коммит-хуках, системах ревью и так далее - в общем, там, где производится проверка качества кода. Замечательно. И как ты предлагаешь осуществлять *динамический* анализ (необходимы, например, для обнаружения UB) средствами IDE, коммит-хуков и прочей ерунды? Инструментацию осуществляет либо компилятор, либо виртуальная машина типа valgrind, первый вариант требует на порядок меньше ресурсов во время выполнения. > Сейчас в clang запихнули то, что должно быть в lint - ну > так кто-то забыл о one responcbility principle (оно же кусок unix > way, кстати) - бывает. Ага, а парсер C/C++ и код для построения и анализа AST и CFG переписать с нуля в каждом из этих инструментов. Отличная идея, бро.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	176. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 22:29
	> Главное, что они написали анализатор, который тычет программистов в их косяки. А, > по-хорошему, этим должен бы заниматься компилятор. Давайте компилятор еще и программы писать начнет вместо программиста? А программистов уволить вообще.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

96. "Оптимизация кода компилятором может привести к появлению про..."	+/–
Сообщение от pavlinux (ok) on 30-Окт-13, 16:14
> подготовлен специальный статический анализатор STACK. Они его ужо открыли?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	112. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Crazy Alex (ok) on 30-Окт-13, 17:13
	git clone git://g.csail.mit.edu/stack
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	219. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от pavlinux (ok) on 31-Окт-13, 15:03
	> git clone git://g.csail.mit.edu/stack Да ладно!?!?!
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

108. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
Сообщение от BratSinot (ok) on 30-Окт-13, 17:05
Мне кажется или подобные "проверки" на выход за пределы сами по себе ошибки?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	149. "Оптимизация кода компилятором может привести к появлению про..."	+4 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 19:51
	> Мне кажется или подобные "проверки" на выход за пределы сами по себе ошибки? Особенно порадовало "if (buf + len < buf)". Хакиры, однако. Про переполнение знают. Но почему чрезмерный размер len надо ловить через столь хитро закрученный болт с левой резьбой - загадка природы.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	220. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от pavlinux (ok) on 31-Окт-13, 15:10
	>> Мне кажется или подобные "проверки" на выход за пределы сами по себе ошибки? > Особенно порадовало "if (buf + len < buf)". Хакиры, однако. Про переполнение > знают. Но почему чрезмерный размер len надо ловить через столь хитро > закрученный болт с левой резьбой - загадка природы. Ваш вариант определения переполнения суммы, при условии, что операнды должны быть одного типа.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	223. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 15:39
	> Ваш вариант определения переполнения суммы, при условии, что операнды должны быть одного > типа. а тут уже не раз приводили, вообще-то. в данном случае — '(UINTPTR_MAX-(uintptr_t)buf) < len', например. с надеждой, что len — size_t или uintptr_t. а если очень хочется «один тип» — то limits.h и xxx_MAX/2. костыли-с.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	271. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от Аноним (??) on 31-Окт-13, 23:45
	так  нельзя, т.к. UINTPTR_MAX может быть больше фактического значения адреса. Вообще не понятеен источник проблемы, во всех операциях с памятью всегда известна максимальная длина рабочего блока, с ним и нужно сравнивать.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	274. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от arisu (ok) on 01-Ноя-13, 06:05
	> так  нельзя, т.к. UINTPTR_MAX может быть больше фактического значения адреса. хм. портабельного метода узнать «место, где Земля закругляется» нет. но и речь шла о проверке на арифметическое переполнение, а не конкретно на валидность указателя. к сожалению, это си: «портабельность» в понимании авторов стандартов — это ни в коем случае не определять фичи, одинаково работающие на большинстве платформ, и уж ни в коем случае не определять фичи, которые способны значительно облегчить портирование. > не понятеен источник проблемы это плохо. > во всех операциях с памятью всегда известна > максимальная длина рабочего блока, с ним и нужно сравнивать. UINTPTR_MAX эта длина. сравниваем.
	Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

	280. "Оптимизация кода компилятором может привести к появлению..."	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 01-Ноя-13, 12:36
	> но и речь шла о проверке на арифметическое переполнение для тупых ещё раз объясняю, uintptr_t может иметь большую битность чем void*, нельзя им проверять переполнение адреса. Что тут может быть не понятным? > UINTPTR_MAX эта длина. сравниваем. это не длина, балбес.
	Ответить | Правка | ^ к родителю #274 | Наверх | Cообщить модератору

	285. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от arisu (ok) on 01-Ноя-13, 13:21
	читать учись, дятел.
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	277. "Оптимизация кода компилятором может привести к появлению..."	–2 +/–
	Сообщение от клоун Стаканчик on 01-Ноя-13, 11:03
	Проблема возникает исключительно при программировании ядра Линукс. Для всех остальных она неактуальна. Из темы ядро никто не разрабатывал, так что идёт общение диванных теоретиков. Источник проблемы - определение момента переполнения беззнакового целого. В ассемблере за это отвечает флаг CF: add esi,eax jc overflow ; <<<< В Си такой конструкции нет. Адекватные люди пишут inline-вставку на ассемблере, но его использование в ядре Линукс запрещено. Дальше начинается обсуждение по типу как открыть входную дверь без ключа если у вас есть пустая консервная банка, бечёвка и окурок.
	Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

	278. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 01-Ноя-13, 11:07
	> Адекватные люди пишут inline-вставку на ассемблере а потом офигевают: отчего это их говнософт не собирается на другой платформе? ах, ну да: ведь кроме x86 на свете ничего нет. ну, x86_64 ещё по праздникам. всё равно любимая винда больше нигде не работает нормально.
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	282. "Оптимизация кода компилятором может привести к появлению..."	–2 +/–
	Сообщение от клоун Стаканчик on 01-Ноя-13, 13:03
	Для реализации специфического функционала делают HAL. Внешне код из: #ifdef X86 ... #else ifdef ARM ... #endif Превращается в элегантное: func(); А все эти ifdef уходят в единственный файл: #ifdef X86 include "x86\file.c" #else ifdef ARM include "arm\file.c" #endif Тут я один профессионально программированием занимаюсь?
	Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

	286. "Оптимизация кода компилятором может привести к появлению..."	+2 +/–
	Сообщение от arisu (ok) on 01-Ноя-13, 13:22
	> Для реализации специфического функционала делают HAL. …и радостно вызывают *внешнюю* *функцию* для сложения. круто. я понимаю, почему винда так тормозит: её писали подобные тебе — тоже безмозглые, но усердные.
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

	287. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от клоун Стаканчик on 01-Ноя-13, 13:46
	inline bool isOverflow(ptr,size); if(isOverflow(buf,len))fail();
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	288. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 01-Ноя-13, 13:49
	других операций у нас не бывает, ага.
	Ответить | Правка | ^ к родителю #287 | Наверх | Cообщить модератору

	289. "Оптимизация кода компилятором может привести к появлению..."	–1 +/–
	Сообщение от клоун Стаканчик on 01-Ноя-13, 14:24
	Не затруднит привести пример кода на Си, который, по твоему мнению, нельзя выделить в отдельную функцию?
	Ответить | Правка | ^ к родителю #288 | Наверх | Cообщить модератору

	298. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Ноя-13, 15:13
	> Тут я один профессионально программированием занимаюсь? Разве что себя, поскольку одноплатформенный профессионал -- это оксюморон.
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

	279. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от тоже Аноним (ok) on 01-Ноя-13, 11:07
	> Адекватные люди пишут inline-вставку на ассемблере И очень этим радуют неадекватных людей, которые собирают не только под x86. Только почему-то потом эти неадекваты запрещают использовать ассемблер в ядре.
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	281. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 01-Ноя-13, 12:41
	> Проблема возникает исключительно при программировании ядра Линукс. в ядре всегда известна модель памяти. И нигде нет необходимости проверять переполнение указателя, это выдуманная проблема.
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	297. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Ноя-13, 15:10
	> Из темы ядро никто не разрабатывал Врёте.
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	273. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от pavlinux (ok) on 01-Ноя-13, 02:33
	В общем если так дрочить код, то проще изначально не создавать проблем.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	275. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 01-Ноя-13, 06:07
	p.s. $#%%&#! павлин, ну хлоп твою железку! ну перестань же ПОЛНОСТЬЮ посты переделывать, я же с почты отвечаю и не всегда обращаю внимание на процитированый текст — особенно если там одна строка!
	Ответить | Правка | ^ к родителю #273 | Наверх | Cообщить модератору

	323. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Аноним (??) on 02-Ноя-13, 10:45
	> Ваш вариант определения переполнения суммы, Изначально неверная постановка задачи. На самом деле цель - поймать выход за границы буфера.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

133. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
Сообщение от Аноним (??) on 30-Окт-13, 18:23
Пардон, но если программист в своём коде допускает случаи, когда поведение программы может стать неопределенным, то проблема именно в программисте и его плохом знании стандартов языка. Рекомендую почитать статьи разработчиков PVS-Studio, которые постоянно подчеркивают, что если вы полагаете "а, ничего страшного, вряд ли когда-нибудь эта переменная станет неопределенной", то рано или поздно: a) это произойдет; б) вы потратите уйму времени, чтобы найти причину. Именно поэтому нужно изначально максимально точно следовать стандартам.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	141. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от клоун Стаканчик on 30-Окт-13, 18:57
	Это называется парадокс римского права: знать все законы невозможно, при этом незнание законов не избавляет от ответственности. В рамках строгой логики данный парадокс неразрешим.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	174. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 22:28
	> что если вы полагаете "а, ничего страшного, вряд ли когда-нибудь эта > переменная станет неопределенной", то рано или поздно: a) это произойдет; б) > вы потратите уйму времени, чтобы найти причину. Именно так - при том уповать на то что не описано в стандарте и/или "а вроде работает же" чревато тем что однажды работать таки перестанет. При том в самом неожиданном месте. Достаточно вспомнить про абобу, memcpy и флеш, где странные люди зачем-то полагались на конкретное поведение memcpy() хотя в стандарте ничего не говорится как именно должен работать memcpy кроме того что он скопирует что попросили куда попросили.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	209. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 09:12
	> на конкретное поведение memcpy() хотя в стандарте ничего не говорится как > именно должен работать memcpy кроме того что он скопирует что попросили > куда попросили. притом в конкретно описаной ситуации. и там же сказано, что в другой ситуации поведение не определено: может хоть «кукарачу» петь.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	222. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от pavlinux (ok) on 31-Окт-13, 15:21
	>> что если вы полагаете "а, ничего страшного, вряд ли когда-нибудь эта >> переменная станет неопределенной", то рано или поздно: a) это произойдет; б) >> вы потратите уйму времени, чтобы найти причину. > Именно так - при том уповать на то что не описано в > стандарте и/или "а вроде работает же" чревато тем что однажды работать > таки перестанет. При том в самом неожиданном месте. > Достаточно вспомнить про абобу, memcpy и флеш, где странные люди зачем-то полагались > на конкретное поведение memcpy() хотя в стандарте ничего не говорится как > именно должен работать memcpy кроме того что он скопирует что попросили > куда попросили. Всё такие вумные. Если уж вдаваться в абсолютизм, то НЕЛЬЗЯ ОБЕСПЕЧИТЬ КОРРЕКТНОСТЬ КОДА СРЕДСТВАМИ ЭТОГО ЖЕ ЯЗЫКА, более того - даже СРЕДСТВАМИ ЭТОГО АЛФАВИТА. Можно до усрачки проверять результат работы if ( a > b )    if ( a - b > 0 )       if ( -b + a > 0 )         if  ( asm("test" "a" "b") == 0 ) .... В каждой из выше описанных строк, нужно проверять корректность операций if, >, <, ==, -, +, ...,   а затем проверить корректность проверки,... :) То есть, нельзя на компьютере написать программу проверки кода, который будет работать на этом же компьютере!!! Первым приближением к истине может быть чекер написанный на LISP/Ada/Scala под OpenVMS на Alpha или Itanium 2
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	225. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от Crazy Alex (ok) on 31-Окт-13, 15:40
	Этот абсолютизм к реальной жизни ни малейшего отношения не имеет.
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	259. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от pavlinux (ok) on 31-Окт-13, 17:43
	> Этот абсолютизм к реальной жизни ни малейшего отношения не имеет. Нужно добавить к твоей реальной жизни. В институтах, на мех.-мате МГУ, в МИФИ,... много работ по этой теме.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	231. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 15:51
	> То есть, нельзя на компьютере написать программу проверки кода, который будет работать > на этом же компьютере!!! чушь. возможно, даже в случае, когда не гарантируется, что все «примитивы» работают корректно (хотя в этом случае, конечно, намного сложнее, чем если принять за данность корректное поведение «примитивов» — и да, есть граничные условия).
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	261. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от pavlinux (ok) on 31-Окт-13, 17:53
	>> То есть, нельзя на компьютере написать программу проверки кода, который будет работать >> на этом же компьютере!!! > чушь. возможно, даже в случае, когда не гарантируется, что все «примитивы» работают > корректно (хотя в этом случае, конечно, намного сложнее, чем если принять > за данность корректное поведение «примитивов» — и да, есть граничные условия). Знаешь такую фичу, что корректность перевода на иностранный язык, с целью понимания, - есть обратный перевод. Ну или по нашему - дизассемблирование. Вроде test eax, ebx  и cmp eax, ebx одно и тоже, но на разных наречиях... Для понимания этих наречий и нужон "алфавит дизассемблера".
	Ответить | Правка | ^ к родителю #231 | Наверх | Cообщить модератору

	262. "Оптимизация кода компилятором может привести к появлению..."	+1 +/–
	Сообщение от arisu (ok) on 31-Окт-13, 17:58
	> Вроде test eax, ebx  и cmp eax, ebx одно и тоже, но на разных наречиях… это для тех, кто язык плохо выучил. а для тех, кто хорошо выучил — «есть нюанс».
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	272. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от pavlinux (ok) on 01-Ноя-13, 01:55
	>> Вроде test eax, ebx  и cmp eax, ebx одно и тоже, но на разных наречиях… > это для тех, кто язык плохо выучил. а для тех, кто хорошо > выучил — «есть нюанс». Этот нюанс зовётся компилятор, ибо на C ты напишешь  if ( x == 0 ), а компулятор сделает как ему "нравиться"  иль test ax, ax или cmp ax, 0; Не, ещё хуже - компилер скомпилит в двухбайтовую команду, скажем 0x0b12 или 0x0b10, а чё там сделает процессор - хрен знает.   Вот так незаметно и подошли к тому, что логическая бага (фича) в проце, влияет как на работу проверяемого, так и проверяющего.
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	276. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 01-Ноя-13, 06:09
	> Этот нюанс зовётся компилятор нет, этот нюанс зовётся «процессор». test — это побитовый and, видишь ли, а cmp — это sub.
	Ответить | Правка | ^ к родителю #272 | Наверх | Cообщить модератору

	316. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от pavlinux (ok) on 02-Ноя-13, 02:14
	>> Этот нюанс зовётся компилятор > нет, этот нюанс зовётся «процессор». test — это побитовый and, видишь ли, > а cmp — это sub. Ну вот и представь ституёвину, когда программа после команды test "ломается", там же и ломается чекер. Другой язык использует для проверки той же ситуации cmp.
	Ответить | Правка | ^ к родителю #276 | Наверх | Cообщить модератору

	326. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 02-Ноя-13, 11:03
	если предполагается, что примитивы могут косячить, то не поверишь — сначала проверяют примитивы.
	Ответить | Правка | ^ к родителю #316 | Наверх | Cообщить модератору

	333. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от pavlinux (ok) on 03-Ноя-13, 02:08
	> если предполагается, что примитивы могут косячить, то не поверишь — сначала проверяют > примитивы. Ну вот слава яйца, хоть народ до компилятора добрался и отловили описанные в новости баги.
	Ответить | Правка | ^ к родителю #326 | Наверх | Cообщить модератору

147. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
Сообщение от Аноним (??) on 30-Окт-13, 19:42
Выход один, компилятор должен компилировать, а вот оптимизировать ли код должен решать конечный пользователь компилятора. Согласен с оптимизацией значит должен понимать что приносишь в жертву.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	152. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от const86 (ok) on 30-Окт-13, 20:14
	Это полумера. Достаточно заковыристый код может и без оптимизатора стать дырой в безопасности.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	175. "Оптимизация кода компилятором может привести к появлению про..."	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-13, 22:28
	> Выход один, компилятор должен компилировать, а вот оптимизировать ли код должен решать > конечный пользователь компилятора. gcc -O0 вам в руки :)
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	186. "Оптимизация кода компилятором может привести к появлению про..."	–1 +/–
	Сообщение от Сталин on 31-Окт-13, 00:56
	gcc -O0  | upx -9
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

191. "Оптимизация кода компилятором может привести к появлению..."	+4 +/–
Сообщение от arisu (ok) on 31-Окт-13, 08:22
после первого говнопримера читать прекратил: результат 'buf + len' при переполнении тупо не определён. «группе исследователей» — гоугоу читать стандарты, а потом уже делать заявления. дятлы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

244. "Оптимизация кода компилятором может привести к появлению про..."	+/–
Сообщение от Аноним (??) on 31-Окт-13, 16:27
Это просто ещё одно доказательство, что убогий сипипи не приспособлен для промышленного, да и вообще мэйнстримного программинга - низкоуровневые выкрутасы ничего не говорят о намерениях (ошибочных или нет) программиста. Пора уже блин обратить внимание на Ди - на порядок повысить уровень программ!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	247. "Оптимизация кода компилятором может привести к появлению..."	+/–
	Сообщение от arisu (ok) on 31-Окт-13, 16:32
	> Пора уже блин обратить внимание на Ди а они там уже перестали язык-то перетрясать? и стандартные библиотеки? пока что D — не смотря на хороший зачин — для «production» никак не готов. «ой, мы обновили компилятор или библиотеку, поэтому ваш старый код больше не соберётся» — это не то, что помогает разрабатывать большие продукты. для альтернативщиков: я НЕ СКАЗАЛ, что D — плохой. тем более не сказал, что он хуже C++.
	Ответить | Правка | ^ к родителю #244 | Наверх | Cообщить модератору

	263. "Оптимизация кода компилятором может привести к появлению про..."	+/–
	Сообщение от тоже Аноним (ok) on 31-Окт-13, 18:38
	> Это просто ещё одно доказательство, что убогий сипипи не приспособлен для промышленного, да и вообще мэйнстримного программинга Вообще-то это аксиома: любой убогий язык не приспособлен для мэйнстрима. Просто вы почему-то думаете, что убогость языка зависит не от того, кто на нем пишет. Или не знаете, что большая часть мэйнстрима писалась и пишется на тех языках, от которых вас так высокомерно морщит. А пафосно-великолепный Д так к мэйнстриму никем и не приспособлен. Примерно так же, как и прочие панацеи на бумаге. Тут кто-то заявлял, что на С всегда полные исходники говнокода. Забывая, что этот ужасный говнокод эффективен, а идеально прекрасные абстракции на какой-нибудь Жаве тратят ресурсы не на работу, а на поддержку этих идеальных абстракций...
	Ответить | Правка | ^ к родителю #244 | Наверх | Cообщить модератору

335. "Оптимизация кода компилятором может привести к появлению про..."	+/–
Сообщение от rihad on 06-Ноя-13, 16:41
Код сам неосторожно написан. Компилятор просто следует стандарту, а стандарт гласит, что любая арифметика на указателях должна ссылаться на один и тот же массив, выходя не больше, чем на 1 элемент после него. Поведение программы в противном случае не определено.    char *buf = ...;    char *buf_end = ...;    unsigned int len = ...;    if (buf + len >= buf_end)       return;  /* len too large */    if (buf + len < buf)       return; /* overflow, buf+len wrapped around write to buf[0..len-1] */ Во второй проверке, результат сложения в случае переполнения ссылался бы до объекта, поэтому поведение было бы не определено. Значит компилятор избегает неопределенного поведения. Лучше было бы вместо обоих условий простое if (buf_end - buf <= len) return; Во втором примере    struct tun_struct *tun = ...;    struct sock *sk = tun->sk;    if (!tun)       return POLLERR; /* write to address based on tun */ Если бы tun было NULL, обращение tun->sk не определено. Опять же, компилятор избегает не определенного кода if (!tun).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

337. "Оптимизация кода компилятором может привести к появлению про..."	+/–
Сообщение от IRASoldier on 18-Июн-18, 12:15
Компилятор выкидывает из кода костыли и грязные хаки (" неопределённые или нестабильные участки кода") - виноват компилятор, а не писатель костылей и грязных хаков, мда.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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