Почитай приколы про memcpy. А ведь куча лохов не обращала внимания на предупреждение в манах! И напоролись!!!

Да тот же битовый сдвиг на отрицательную величину (либо на величину, превышающую количество разрядов типа). Если я правильно помню, gcc и clang дают разные результаты.

Где их найти? Загуглил «приколы с memcpy», нашел это http://habrahabr.ru/post/150970/ - там не то и вообще какая-то хрень. google://memcpy+optimized+out тоже ничего вроде не принесло.

Не, ну это понятно, это фиг с ним. Вот мне бы такой пример, когда компилятор смотрит код «ага, тут определенно случится UB, значит будем считать, что код дальше этого UB никогда не будет достигнут, значит можно его выкинуть» или что-то подобное, а не просто какую-то штуку, которая в разных компиляторах по-разному работает.

Гугли «memcpy overlapped memory»

Было что-то про мелкомягких дебилов и еще каких-то быдлокодеров, у которых «серьезный» софт грохнулся по причине невнимательного чтения манов.

На тебе еще хрень:

++a += a++ + ++a;
b = --b - b--;
if(!a || !*a);

Ну, а насчет «оптимизаций» — попробуй сделать пустой цикл для небольшой паузы на мелкоконтроллере, или же запили что-нибудь вроде

i = 0;
while(!i);

Ну и т.д., и т.п.

например

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

http://blog.regehr.org/archives/759

Здесь вряд ли UB, т.к. все компиляторы инициализируют глобальные переменные нулями.

[offtopic]
Ура! На ЛОРе нормально заработала фильтрация тегов: черный список теперь в приоритете!!! В трекере эта тема не висит ☺
[/offtopic]

Спасибо за первую ссылку. Я смог сделать пример с signed integer overflow, который мне нравится, который на разных уровнях оптимизации выдает разное.

Соответственно если этот number < number + 1 добавить в if, то вероятно можно сделать так, чтобы компилятор выпилил код ненужный, и на разных уровнях оптимизации выполнялись разные ветки кода.

// ========== main.cpp ==========

#include <iostream>

extern signed int number;

int main()
{
    std::cout << "number = " << number << std::endl;
    std::cout << "number + 1 = " << number + 1 << std::endl;
    std::cout << "number < number + 1 = " << (number < number + 1) << std::endl;
    return 0;
}



// ========== library.cpp ==========
#include <limits>

signed int number = std::numeric_limits<int>::max();

Компилятор Desktop Qt 5.5.0 MinGW 32bit

Результат без оптимизаций:

number = 2147483647
number + 1 = -2147483648
number < number + 1 = 0

-O3:

number = 2147483647
number + 1 = -2147483648
number < number + 1 = 1

Еще мне интересно, считают ли компиляторы signed integer overflow за undefined behaviour и оптимизируют ли программу, учитывая тот факт, что это запрещено?

По стандарту это UB, но это широко используется и не является UB с точки зрения конкретных компиляторов.

Цитата:

5.0.4 If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined. [ Note: most existing implementations of C++ ignore integer overflows. ...]

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

Стандарту вообще такое бы стоило описать как unspecified behavior.

А что такое вообще unspecified behaviour в C и C++? Пару раз этот термин рандомно в обсуждениях слышал, но ничего авторитетного и с подробностями не читал.

unspecified behavior

behavior, for a well-formed program construct and correct data, that depends on the implementation [ Note: The implementation is not required to document which behavior occurs. The range of possible behaviors is usually delineated by this International Standard. —end note ]

implementation-defined behavior

behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents

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

Насколько помню, тут хорошо писали. Пока искал эту заметку, нашёл ещё две; первую не помню, а вторая хорошо иллюстрирует неожиданное поведение программы.

Еще мне интересно, считают ли компиляторы signed integer overflow за undefined behaviour и оптимизируют ли программу, учитывая тот факт, что это запрещено? Мне кажется, было бы наиболее разумно им делать вид, что это поведение вполне себе определено, и не выпиливать из-за этого код, потому что по-моему 90% C++ программистов, да и C программистов тоже не знают о том, что это UB.

Компиляторы не считают что-то за undefined behaviour, это делает стандарт. А вот компиляторы в случае, когда код подразумевает undefined behaviour, просто ведут себя так, как им удобно. Могут предупреждение/ошибку выдать, но чаще просто делают то же, что обычно в «подобной» ситуации, не задумываясь о последствиях. В случае с signed integer, например, просто генерируют тот же бинарный код. А UB заключается в том, что на одной архитектуре переполнение приведет к одному значению в переменной, а на другой - к другому, или вообще к ошибке.

Досконально не помню пример, но был случай, когда было написанно что то типа:

parse(pointer++, pointer);

Вроде даже в рамках одного компиля сиё проявлялось. Ток обьект был чуть посложнее по семантике, чем просто указатель. А функа выводилась из шаблона и была inline.

Почитай стандарт, там суховато, но зато формально описанно, если не осиливаешь - почитай Алёну.

Где ты видишь ub? В обоих твоих примерах его нет.

по-моему 90% C++ программистов, да и C программистов тоже не знают о том, что это UB

Программисты, знающие все случаи UB - это вообще вымирающий вид. Очень уж веселый язык си, про плюсы можно и не говорить.

По сабжу - ищи статьи PVS Studio, adobe memcpy bug, strict aliasing break, NULL dereference optimization.

if(!a || !*a);

Это не ub.

Это победа

Падает даже без оптимизаций. Но по-другому.

Это победа

Да, пока это самое эпичное что я видел. Не понимаю почему им не сделать -Werror=return-type по умолчанию, потому что это чревато чем угодно. Но таки да, по стандарту они правы на 100%.

Падает даже без оптимизаций. Но по-другому.

Без оптимизаций оно вставляет ud2, с оптимизациями просто проваливается в следующую функцию. На самом деле раньше (наверное на clang 3.4, сейчас 3.6) оно с оптимизациями даже и не падало.

хотелось бы примеры, как именно undefined behaviour приводит к тому, что оптимизации компилятора делают так, что код делает не то, что днище-программисту кажется, что он должен делать

http://edunow.su/site/content/cpp/oproverzhenie-teoremy-ferma-i-ub

http://habrahabr.ru/post/229963/

int table[4];
bool exists_in_table(int v)
{
    for (int i = 0; i <= 4; i++) {
        if (table[i] == v) return true;
    }
    return false;
}

int main()
{
    table[0] = 0;
    table[1] = 1;
    table[2] = 2;
    table[3] = 3;

    cout << "10 in table " << exists_in_table(10);
}

Может вернуть истину при оптимизации, хотя 10 в массиве нет.

Ещё красивый пример:

struct timeval tv;
unsigned long junk;
 
gettimeofday(&tv, NULL);
srandom((getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk);

clang превращает в

struct timeval tv;
unsigned long junk;
 
gettimeofday(&tv, NULL);
getpid();
srandom(0);

Или такой прикол:

#include <stdio.h>
#include <stdlib.h>

int main() {
int *p = (int*)malloc(sizeof(int));
int *q = (int*)realloc(p, sizeof(int));
*p = 1;
*q = 2;
if (p == q)
   printf("%d %dn", *p, *q);
}



$ clang -O realloc.c ; ./a.out 
1 2

два значения по одному адресу.

Вот ещё замечательная оптимизация:

enum {N=32};
int a[N], pfx[N];
void prefix_sum()
{
  int i, accum;
  for (i=0, accum=a[0]; i < N; i++, accum+=a[i])
    pfx[i] = accum;
}

gcc-4.8.0 делает из этого бесконечный цикл. И вполне имеет право выкинуть проверку на i < N, так как иначе UB.

А ты на 100% уверен, что на сферической в вакууме машине компилятор не проверит сначала второе условие?

хотелось бы примеры, как именно undefined behaviour приводит к тому, что оптимизации компилятора делают так, что код делает не то, что днище-программисту кажется, что он должен делать.

int a = 0;
int b = a++ + ++a;

Я смотрю, шланг — вообще жесть, а не компилятор!

шланг всего лишь «строго соответствует стандарту». А вот кому в голову пришла мысль в стандарт вводить понятие UB как разрешения делать ЧТО УГОДНО — это вопрос.

на 100% уверен, что на сферической в вакууме машине компилятор не проверит сначала второе условие

Да. В стандарте прописан жёсткий порядок для || и &&

Я помню только о &&, а насчет || — не факт!

Нафиг нужен компилятор, поведение которого невозможно предсказать?

Для стандарта С++ 2011 пункт 5.15 Logical OR operator: ... Unlike |, || guarantees left-to-right evaluation; moreover, the second operand is not evaluated if the first operand evaluates to true.

Нафиг нужен компилятор, поведение которого невозможно предсказать?

На самом деле вопрос звучит так: «Нафиг нужен язык, поведение программы на котором невозможно предсказать?». Компиляторы всего лишь соответствуют стандарту языка.

При чем здесь этот говноязык? Я о нормальном С говорю!

Языку С уже дофига лет! Он уделал асм, форт, фортран, паскаль, аду, …

И до сих пор никто не придумал язык лучше С!!! Деннис Ритчи — воистину БОХ!

Деннис Ритчи — воистину БОХ!

А Керниган с Пайком?

Рядом стояли?

Он уделал асм,

никогда не умрет

форт,

помощь зала!

фортран,

но-но! бласы с лапаками используешь, небось?

паскаль, аду, …

виртоидеи повлияли на жаву

Я о нормальном С говорю!

ОК, В ISO/IEC 9899:TC2 в пункте 6.5.14 написано «Unlike the bitwise | operator, the || operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares unequal to 0, the second operand is not evaluated.»

Рядом стояли?

Еретик.

Языку С уже дофига лет!

И все эти годы проблемы переносимости решаются исключительно пачками ifdef'ов. И при переходе на другой компилятор или ОС всегда надо заново прогонять все тесты (и надеяться, что из достаточно).

никогда не умрет

Только из-за «железячных» особенностей.

бласы с лапаками используешь, небось?

Они уже давным-давно на С переписаны!

виртоидеи повлияли на жаву

Лучше бы этой жабки не было никогда!

А ты уверен, что какие-нибудь быдлокодеры из мелкомягкой конторы (или нетрадиционные лица из огрызка) внимательно читали стандарты при создании компилятора под свой шлак? Мне-то пофиг, но ...