[AHTOXA 18]

UB = undefined behavior.

[k000858 0]

Качество кода lwip во всей красе, UB на UB и UB погоняет.

въехать бы тебе в сакральный смысл данного поста

[Kabdim 0]

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

Ну и что бы не быть совсем флудером: What Every C Programmer Should Know About Undefined Behavior

[k000858 0]

ок. а в рамках обсуждаемого предмета (баг, я так понимаю в lwip который проявляется с GCC 5) можно разжевать что там к чему дабы не вдаваться в ассемблерный код?

[scifi 1]

ок. а в рамках обсуждаемого предмета (баг, я так понимаю в lwip который проявляется с GCC 5) можно разжевать что там к чему дабы не вдаваться в ассемблерный код?

При выходе за границу массива компилятор генерирует код, который не то, чтобы просто за границу массива выходит, а лезет в совершенно левые адреса.

[k000858 0]

При выходе за границу массива компилятор генерирует код, который не то, чтобы просто за границу массива выходит, а лезет в совершенно левые адреса.

Вот как раз что то подобное в паре проектов у себя наблюдаю...

только вот выходы за границу массивов не наблюдаю...

[Kabdim 0]

Если есть повторяемость где бьются данные, то всегда можно поставить watchpoint в нужное место и выяснить кто и где бьёт.

[Сергей Борщ 143]

Ну и что бы не быть совсем флудером: What Every C Programmer Should Know About Undefined Behavior

Прочитал. Долго втыкал в код

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
}

Так и не понял, где тут ошибка.

This behavior enables an analysis known as "Type-Based Alias Analysis" (TBAA) which is used by a broad range of memory access optimizations in the compiler, and can significantly improve performance of the generated code. For example, this rule allows clang to optimize this function:

float *P;
void zero_array() {
   int i;
   for (i = 0; i < 10000; ++i)
     P[i] = 0.0f;
}

into "memset(P, 0, 40000)". This optimization also allows many loads to be hoisted out of loops, common subexpressions to be eliminated, etc. This class of undefined behavior can be disabled by passing the -fno-strict-aliasing flag, which disallows this analysis. When this flag is passed, Clang is required to compile this loop into 10000 4-byte stores (which is several times slower), because it has to assume that it is possible for any of the stores to change the value of P, as in something like this:

 

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
}

Кто-то может объяснить?

 

Про переполнение знаковых целых как аргументов для функций выделения памяти - сами себе злобные Буратины: нафига размер передавать знаковой переменной? К тому же есть беззнаковый тип size_t. Но в целом да, раскрыты некоторые неочевидные вещи.

[Kabdim 0]

С оптимизацией в примере будет обнулен буфер 40КБ, начало которого совпадает с началом переменной P. Без оптимизации будет обнулен указатель, а последующие записи пойдут по адресам 0+i. Оба варианта конечно совершенно невменяемые, но примерам такое можно простить. В следующих частях мне показалось рассказывают еще интересней.

[Сергей Борщ 143]

Удалил. Понял.

[k000858 0]

кстати вся инфа актуальна только на оптимизации -Os?

или на -Og так же актуально?

 

[Kabdim 0]

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

[scifi 1]

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

Если не ошибаюсь, в этом случае lwip и не только он идут лесом. Слишком радикально, нет? Проще включить опцию -fno-strictaliasing.

[Kabdim 0]

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

[scifi 1]

А потом может будет внедрена еще какая-нибудь оптимизация и грабля снова сработает, но уже так что будет совершенно неясно где корень зла. Или не сработает, как повезет.

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

Но да, надо следить за модой и писать как в лучших домах Лондона и Парижа. Чтобы потом деревенщиной не прозвали