Странное предупреждение Опции

[Jenya7]

Есть такая строчка в коде

Код

for (i=0; i < size_to_take; i++)
{
      DataBuffer[i] = (data_out[j++]<<8) | data_out[j++];
}

Выскакивает предупреждение

Warning[Pa079]: undefined behavior: variable "j" (declared at line 176) (or a value reached by some form of indirection through it) is modified more than once without an intervening

В GCC компайлере такого предупреждения нет.Что надо переделать чтоб предупреждение исчезло?

[juvf]

ну на конец то предметный разговор, а не "слепая вера"

Попробуйте когда-нить

попробую обязательно.

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

Это я слышал и/или знаю.... Но, во первых, современные оптимизаторы иногда портят код так, что он не работает как надо, приходится либо отключать оптимизацию полностью, либо на отдельной функции. Во вторых про потуги вы зря.... когда мой код перестал влазить в флешь, а в прерываниях стал долго задерживаться, то сделал рефакторинг - код и влез и стал быстрее работать. Одна строчка до рефакторинга была 6 машинных команд, стала 2 или 4.
Убрал всякие лишние << |, на каждом участке экономил где по 10-20 байт флеша, где по 100.

во-вторых: ничего не известно о значении size_to_take, а если она перед началом цикла может быть отрицательной (и i - тоже знаковое)

Морите!? О чем тут дискутировать, если вы не знаете как работает for? Если size_to_take отрицательная и i тоже знаковое, то в примере ТС в тело цикла for не разу не зайдем. Это вообще букварь Си.

с чего Вы приводите входные аргументы к типу void *?

Да, согласен, неточность есть. Если быть скрупулёзным к явным преобразованиям, то нужно так
memcpy((void*)DataBuffer, (const void*)&data_out[j], 2*size_to_take);
Я не утверждаю, я всего лишь предположил, что копировать память лучше через memcpy. Если это не 8 и 16 бит, то забыли про мой совет. О чем спор?

А если у ТС-а DataBuffer и data_out объявлены к примеру с модификатором volatile

И что? в чем разница вот в таких кодах с volatile (архитектура ст первый, без перевёртывания):
Вариант 1:

Код

volatile uint16_t DataBuffer[100];
volatile uint8_t data_out [1024];
uint16_t size_to_take = 100;
uint8_t j = 17;
for(uint16_t  i=0; i<size_to_take; i++ )
{
   DataBuffer[i] = (data_out[j] << 8)| data_out[j+1];
   j += 2;
}

Вариант 2:

Код

volatile uint16_t DataBuffer[100];
volatile uint8_t data_out [1024];
uint16_t size_to_take = 100;
memcpy((void*)DataBuffer, (const void*)&data_out[17], 2*size_to_take);

Или по вашему 1-ый вариант работать будет, а второй нет?

[jcxz]

Но, во первых, современные оптимизаторы иногда портят код так, что он не работает как надо, приходится либо отключать оптимизацию полностью

А вот здесь: код в студию!
Ибо в 99.9% таких случаев причина - баг в коде.
Я даже скажу больше: я при отладке кода проверяю его работу с включенной и отключенной оптимизацией - это помогает находить скрытые баги в коде.

[juvf]

Продолжаем думать дальше. Подсказываю ещё раз: А что будет с Вашим вариантом на memcpy()?

Что за глупость? при чем тут memcpy с отрицатеольными size_to_take? В коде ТС явно size_to_take > 0.

А вот здесь: код в студию!

Код

#pragma optimize=none
unsigned int crc16_byte(unsigned int crc, unsigned int data)
{
    //const unsigned int Poly16=0xA001;
    unsigned int LSB;
    crc = ((crc^data) | 0xFF00) & (crc | 0x00FF);
    for (uint8_t i=0; i<8; i++)
    {
        LSB=(crc & 0x0001);
        crc >>= 1;
        if(LSB)
            crc=crc^0xA001;
    }
    return crc;
}

Такой код работает, если убрать прагму, то црц считается не правильно. Для фантазёров, видящих за рамками кода всякое ООП, перегрузку операторов, переопределение типов и прочую фуе ту.... перегрузки операторов нет, переопределений типов и чего либо ещё нет. тип unsigned int 16 бит!

[scifi]

Такой код работает, если убрать прагму, то црц считается не правильно. Для фантазёров, видящих за рамками кода всякое ООП, перегрузку операторов, переопределение типов и прочую фуе ту.... перегрузки операторов нет, переопределений типов и чего либо ещё нет. тип unsigned int 16 бит!

Не видно в этом коде никакого криминала. Конечно, нельзя исключить того, что криминал возникает вне этой функции (она же не в вакууме существует). Опять же, не исключён глюк компилятора. У меня яр для coldfire неправильно считал MD5 при включенной оптимизации. Поймать его за руку на конретной инструкции сложно, так как код MD5 зубодробительный.

[juvf]

Конечно, нельзя исключить того, что криминал возникает вне этой функции (она же не в вакууме существует).

Я тоже про это думал. На весь проект стоит максимальная оптимизация по размеру кода. Дебажил на уровне Си, в асм углубляться не стал. Одна строчка #pragma optimize=none давала правильную работу расчета црц. Поэтому врят-ли что-то в остальном коде не так. Времени не было искать глюк в компиляторе или ещё где.... Видимо это был 0,1%.

кому интересно, компилятор IAR C/C++ for STM8 из иара 3,10,1