[IF_P 1]

IAR такие ошибки, вроде, видит. Но как такое мог пропустить - не заметить "=" ? Компилятор IAR AVR 6.80.5 - Atmega128, без оптимизации. Правильный код "YES.jpg" Atmega128

[aaarrr 69]

Так это не ошибка. Возможно, генерация соответствующих предупреждений отключена.

[IF_P 1]

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

 

Вот даже 2 дня назад выдавало предупреждение в аналогичнм случае.

 

P.S.

 

Вот попробовал изменить в другом месте. Все нормально работает.

Изменено 5 июля, 2022 пользователем IF_P

[jcxz 197]

В 05.07.2022 в 14:48, IF_P сказал:

IAR такие ошибки, вроде, видит. Но как такое мог пропустить - не заметить "=" ?

А в чём "ошибка"? Компилятор всё сделал правильно.

В 05.07.2022 в 15:22, IF_P сказал:

Вот даже 2 дня назад выдавало предупреждение в аналогичнм случае.

Вот попробовал изменить в другом месте. Все нормально работает.

Видимо в этом случае и в исходном посте - разные коды, а не "аналогичный случай". Смотрите внимательнее на свой код.

Не знаю что такое у вас max_tab_fram, но видимо - переменная или volatile-константа. В таком случае - нет причин выдавать какие-либо предупреждения, так как результат операции присваивания заранее неизвестен. И компилятор вполне логично считает, что в if () проверяется результат присваивания (т.е. - значение max_tab_fram).

А во втором случае - присваивается константа, значение которой известно на этапе компиляции. Т.е. - нет смысла в runtime проверять результат этой операции присваивания. Потому и генерится варнинг.

[IF_P 1]

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

[k155la3 26]

32 минуты назад, IF_P сказал:

. . .  компилятор эту ситуацию не проверяет.

Компилятор "думает" что так и надо и программист "в здравом уме". Наличие или отсутствие warn возможно зависит от типа данных (например конструкция if(float) - явная ошибка, в то время как if(int) ошибкой не является)

Классика с "==". Встречал решения, когда человек чтобы не допускать таких "ошибок",  условия в if делал в виде

int iVar;
. . . .
if( 2 == iVar ) . . . .

Проект был большой и я зад-ся изменять все условия на нормально-читабельные. 

 

[jcxz 197]

В 05.07.2022 в 18:30, k155la3 сказал:

Проект был большой и я зад-ся изменять все условия на нормально-читабельные.

Когда с обеих сторон переменные (как у ТС) - это не спасёт.

В 05.07.2022 в 17:49, IF_P сказал:

В таком случае надо внимательно проверять все условные операторы

Да, надо тренировать бдительность. Чтобы враг баг не прошмыгнул.  

[VladislavS 29]

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

[IF_P 1]

On 7/6/2022 at 9:57 AM, VladislavS said:

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

Знать бы еще как этим пользоваться.

 

Вот вчера просмотрел все условные операторы в проекте (около 1500) на нвличие "=". Пока все нормально. Но, конечно, хотелось бы иметь контроль за этим.

Изменено 6 июля, 2022 пользователем IF_P

[pyroman 2]

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

if (tab_numb_fram = max_tab_fram)
{
}
else
{
}

 

как:

 

tab_numb_fram = max_tab_fram;
if (tab_numb_fram)
{
}
else
{
}

По-моему, компилятор всё делает правильно... Нет причин для Warning.

Изменено 6 июля, 2022 пользователем pyroman

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

Формально - да, строка синтаксически правильная, но в таком виде применяется крайне редко. Гораздо реже, чем допускаются опечатки в подобных строках со знаком равенства. ГЦЦ на такие строки выдает предупреждение и предлагает заключать такое выражение во вторые скобки, которые не влияют на исполняемый код, но доказывают компилятору, что вы в своем уме (warning: suggest parentheses around assignment used as truth value [-Wparentheses]). 

 

Проверил на чудом сохранившемся IAR ARM ANSI C/C++ Compiler V4.41A/W32 EVALUATION, Copyright 1999-2005 (17-летняя выдержка!):
 

Warning[Pe187]: use of "=" where "==" may have been intended D:\ххххххххххх\IAP.cpp 82 

Так что ищите в настройках компилятора. Или может это санкции так действуют? 

[Arlleex 136]

Keil uVision тоже умеет ловивть эти ситуации, к слову. В IAR, ИМХО, 146% что эта настройка есть, так как там статический анализ мощнее.

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

Хм, а ведь и правда - IAR не выдает предупреждение в случае, когда по обе стороны от знака равенства находятся переменные. Если с одной стороны константа - предупреждение выдается. Пишите в техподдержку, пусть они разъясняют - это их ошибка или они так и задумывали. 

[jcxz 197]

В 06.07.2022 в 13:47, Сергей Борщ сказал:

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

Не надо говорить за всех. В моём коде такое применяется повсеместно. А опечатки такие даже не помню когда делал - так давно это было.

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

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

55 минут назад, jcxz сказал:

В моём коде такое применяется повсеместно.

Вот именно - в вашем коде. Не надо говорить за всех.