Это должен был быть цикл на 10 итераций с выпрыгиванием из него при определённых обстоятельствах. А получилась только одна итерация.

Искренне считаю, что обнаруживать такую СТРАННУЮ последовательность должен компилятор. Правило: если идёт свободный блок, за которым while без тела, то выдать варнинг. Иначе на while без тела с неволатильными переменными в условии выдавать ремарку. Тело в данном случае - ключевой признак этих правил.


Именно такие странности хотелось бы чтобы компилятор "подчёркивал" при компиляции, как Ворд подчёркивает текст при просмотре. Пример тот самый. Как и у ТС.

Блок может использоваться по причинам совершенно не связанным с ошибкой - локализация объявления переменной, макроподстановка...
Так что не надо стенаний, особенно, если стеной стоите, как мне помится, на "нормальности" while(константа){}

while / if (const) ==> ремарка. Продолжаю считать, как и ранее. Полезные конструкции. С тремя уровнями сообщений компилятора. То бишь с двумя не препятствующими генерации прошивки.

В идеале на pred_while(1) и post_while(0) даже ремарку не выдавать. Если макроса в скобках не было.


Макроподстановку легко обнаружить и учесть. Логика на порядки проще оптимизации кода.

Сообщение отредактировал GetSmart - May 3 2016, 21:36

Вообще-то да, это работа не компилятора, но редактора.
Вернее, той особо развитой в последнее его части, которая анализирует код, делает автозавершение, производит выравнивание и прочее.
Вот с его точки зрения легко предположить отсутствие начала в шаблоне do{}while();

1. Странно, что локализована. Лично мне резануло глаз присваивание константы в цикле, при том что константа объявлена не volatile. Стало быть, весь цикл вообще теряет смысл. И никакие неявные приведения типов тут вообще ни причем.

2. Упрощения, это хорошо. Но приводить упрощенный Си-код вне функции, дело бесполезное. Хотя бы потому, что не понятно, переменные temp1 и temp2 локальные или глобальные.

3. Насчет обязан или не обязан компилер. Конечно не обязан, его дело компилировать. Зато статический анализатор кода сразу завопил бы, с негодованием. Благо в последних IAR встроен C-Stat. Настоятельно рекомендую натравить его на код. Гарантирую(с), он еще много "чудес" выявит в коде.

Если ошибка воспроизводится в такой простой конструкции, то зачем присылать страницы кода?
Переменные temp1 и temp2 локальные, объявление на строчку выше. В исходном коде переменным присваиваются не константы, а результат, возвращаемый функцией. А после условного оператора ещё сотня строк в цикле.
Меня лично смутило, что компилятор без предупреждений выбросил из программы большой фрагмент кода. Это было главное, на что я обратил внимание.
Но раз общественность не забилась в праведном гневе, значит все считают это нормальным. А тогда вопрос и не стоит обсуждать.
Тем более в коде был грешок с приведением типов, на который мне правильно указали.

Еще раз. Нет никакой конструкции. Тот огрызок, что приведен, не позволяет нормально определить источник проблемы.


"Не в преферанс, а в лотерею. Не миллион, а пять тыщ. И не выиграл, а проиграл." (с)

Я только не понял, это вот "в исходном коде не константы", это просто поприкалываться захотелось или на полном серьезе?


А, общественность... Все считают... Тогда другое дело. Это заявка на успех. Желаю удачи.

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

Извините, но я не понял к чему это всё, что Вы написали.
Или Вы считаете, что если я скопирую сюда полный код функции, Вы точно укажете на источник проблемы? Или Вы считаете, что я школьник, и то, что я прислал к делу не имеет отношения, а ошибка в другом месте?
Смею Вас заверить, что это не так.
И проблема воспроизводится именно в том "огрызке", который я разместил, я специально проверял. Для этого больше ничего не нужно, достаточно этот фрагмент разместить в пустом main(). Ну разве что скорректировать названия типов.
И в отзывах была информация, что это характерно не только для компилятора IAR. В gcc тоже проблема воспроизводится.

Опять . Да не проблема это компилятора, ЛЮБОЙ компилятор ОБЯЗАН поступить аналогично. Это АБСОЛЮТНО Ваша проблема связанная с незнаним языка.

Я нигде не писал, что претендую на звание "гуру". Более того, на ошибках учусь с удовольствием, как на своих, так и на чужих.
Но никто не дал на мой вопрос чёткий ответ.
1. Если переменные int16u, то компилятор код выбрасывает. У меня нет вопросов к самому факту этого события. У меня вопрос к тому, почему это происходит без предупреждения (молча). Я не считаю, что это нормальное поведение компилятора.
2. Однако если переменные int32u, то с точки зрения выполнения кода ничего не меняется. Но тем не менее в этом случае, код компилируется (не выбрасывается). Хотя результат также предопределен и известен заранее.
Я уже вроде успокоился по этому поводу, но находятся всё новые люди, которые утверждают, что я не знаю язык, но не дают чёткого ответа, почему компилятор поступает именно так.
Может Вы попробуете?

Предупреждения придуманы для удобства. Они помогают отловить ошибки в коде. Нет никаких стандартов, регламентирующих поведение компилятора в этом вопросе. Более того, авторы компилятора тоже никаких обязательств здесь на себя не берут. Следовательно, вопрос "почему" довольно бесперспективный. Если вас так уж гложет, вам надо добыть исходники этого компилятора и разобраться, что там происходит. Или спросить того, кто делает этот компилятор. В этом форуме, понятное дело, вы таких не найдёте.


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

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

Последний раз, больше даже пытаться не стану. Если десять раз присвоить константу temp1=0x1, хоть что-то изменится, хоть на одном проходе из 10? Если не изменится, то бишь даже без всякой оптимизации, temp1 и temp2 _всегда_ будут иметь одно и то же значение. Результат if (~0x0001!= 0xFFFE) будет отличаться хоть на одном из проходов? И плевать какие там типы, все 10 раз будет одно и то же. А строчка temp2 = temp1; будет вообще игнорироваться.

В итоге, имеем несколько строчек бессмысленного кода, который вырождается в пару присваиваний. И никакого цикла здесь нет. Другой вопрос, когда вместо констант будет присваиваться результат функции. В этом случае, может и дойдет до кривых типов. Но в приведенном куске, с константами, до этого дело даже не доходит.

Меняется. При приведении int16_t -> int32_t происходит расширение знака.

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



Уточнение: мои типы int16u и int32u соответствуют uint16_t u uint32_t. Не уверен, что в этом случае можно говорить о расширении знака.
Когда я говорил "ничего не меняется", я имел в виду, что условие в условном операторе по прежнему всегда true (не зависит от типа переменных), но в одном случае код компилируется, а в другом выбрасывается.