IF_P 1 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба IAR такие ошибки, вроде, видит. Но как такое мог пропустить - не заметить "=" ? Компилятор IAR AVR 6.80.5 - Atmega128, без оптимизации. Правильный код "YES.jpg" Atmega128 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба Так это не ошибка. Возможно, генерация соответствующих предупреждений отключена. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IF_P 1 5 июля, 2022 Опубликовано 5 июля, 2022 (изменено) · Жалоба Во-первых, раньше это работало. Во-вторых, я не нашел где в компиляторе можно отключить эту опцию. Вот даже 2 дня назад выдавало предупреждение в аналогичнм случае. P.S. Вот попробовал изменить в другом месте. Все нормально работает. Изменено 5 июля, 2022 пользователем IF_P Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба В 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 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба У меня сравниваются две переменные. В таком случае надо внимательно проверять все условные операторы, т.к. компилятор эту ситуацию не проверяет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба 32 минуты назад, IF_P сказал: . . . компилятор эту ситуацию не проверяет. Компилятор "думает" что так и надо и программист "в здравом уме". Наличие или отсутствие warn возможно зависит от типа данных (например конструкция if(float) - явная ошибка, в то время как if(int) ошибкой не является) Классика с "==". Встречал решения, когда человек чтобы не допускать таких "ошибок", условия в if делал в виде int iVar; . . . . if( 2 == iVar ) . . . . Проект был большой и я зад-ся изменять все условия на нормально-читабельные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба В 05.07.2022 в 18:30, k155la3 сказал: Проект был большой и я зад-ся изменять все условия на нормально-читабельные. Когда с обеих сторон переменные (как у ТС) - это не спасёт. В 05.07.2022 в 17:49, IF_P сказал: В таком случае надо внимательно проверять все условные операторы Да, надо тренировать бдительность. Чтобы враг баг не прошмыгнул. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladislavS 39 6 июля, 2022 Опубликовано 6 июля, 2022 · Жалоба Сам не пользуюсь, но говорят, что статические анализаторы кода такие ошибки хорошо ловят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IF_P 1 6 июля, 2022 Опубликовано 6 июля, 2022 (изменено) · Жалоба On 7/6/2022 at 9:57 AM, VladislavS said: Сам не пользуюсь, но говорят, что статические анализаторы кода такие ошибки хорошо ловят. Знать бы еще как этим пользоваться. Вот вчера просмотрел все условные операторы в проекте (около 1500) на нвличие "=". Пока все нормально. Но, конечно, хотелось бы иметь контроль за этим. Изменено 6 июля, 2022 пользователем IF_P Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pyroman 2 6 июля, 2022 Опубликовано 6 июля, 2022 (изменено) · Жалоба Из кода дизассемблера видно, что компилятор интерпретирует строку if (tab_numb_fram = max_tab_fram) { } else { } как: tab_numb_fram = max_tab_fram; if (tab_numb_fram) { } else { } По-моему, компилятор всё делает правильно... Нет причин для Warning. Изменено 6 июля, 2022 пользователем pyroman Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 6 июля, 2022 Опубликовано 6 июля, 2022 · Жалоба Формально - да, строка синтаксически правильная, но в таком виде применяется крайне редко. Гораздо реже, чем допускаются опечатки в подобных строках со знаком равенства. ГЦЦ на такие строки выдает предупреждение и предлагает заключать такое выражение во вторые скобки, которые не влияют на исполняемый код, но доказывают компилятору, что вы в своем уме (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 178 6 июля, 2022 Опубликовано 6 июля, 2022 · Жалоба Keil uVision тоже умеет ловивть эти ситуации, к слову. В IAR, ИМХО, 146% что эта настройка есть, так как там статический анализ мощнее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 6 июля, 2022 Опубликовано 6 июля, 2022 · Жалоба Хм, а ведь и правда - IAR не выдает предупреждение в случае, когда по обе стороны от знака равенства находятся переменные. Если с одной стороны константа - предупреждение выдается. Пишите в техподдержку, пусть они разъясняют - это их ошибка или они так и задумывали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 6 июля, 2022 Опубликовано 6 июля, 2022 · Жалоба В 06.07.2022 в 13:47, Сергей Борщ сказал: Формально - да, строка синтаксически правильная, но в таком виде применяется крайне редко. Гораздо реже, чем допускаются опечатки в подобных строках со знаком равенства. Не надо говорить за всех. В моём коде такое применяется повсеместно. А опечатки такие даже не помню когда делал - так давно это было. Сама привычка использовать значение операции присваивания в условных операторах, сама по себе позволяет не путать '=' и '=='. Так как даже на уровне подсознания эти операции воспринимаются как разные. А вот люди, которые боятся использовать результат операции присваивания - они как правило и делают такие ошибки. Имхо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 6 июля, 2022 Опубликовано 6 июля, 2022 · Жалоба 55 минут назад, jcxz сказал: В моём коде такое применяется повсеместно. Вот именно - в вашем коде. Не надо говорить за всех. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться