scmRTOS и IAR EWAVR 4.30 Опции

[IgorKossak]

Скомпилировал сабж и, в отличие от версии IAR 4.21, получил несколько ремарок, касающихся кастинга (Pe1375,Pa091).
Чтобы глаза не мозолили, просто запретил выдавать диагностику на эти ремарки.
Но сомнения гложат, ведь не спроста же они появились. Новая версия IAR стала строже ко всему относиться.
Каким образом можно корректно обойти эти проблемы, чтобы не напороться на неприятности с переносимостью?

[IgorKossak]

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

[dxp]

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

Да там и нет причин, чтоб не работало.

Так что пока запретил выдавать эти сообщения во всем проекте. Далее если будет не лень обрамлю проблемные строки соответствующими прагмами.

Когда-то когда ремарки только появились, я тоже начал ими пользоваться, надеясь и полагая, что они помогут писать более логичный и безопасный код, но очень быстро от них отказался по причине того, что частенько замечания выдавались не по делу (как и рассматриваемом случае), зато более серьезные места оставлены без внимания. Например, в контексте scmRTOS: есть момент, когда в конструкторах объектов производится запись в таблицу процессов (регистрация процессов в ядре), таблица процессов размещена в объекте Kernel, который сам является объектом класса, у которого тоже есть конструктор. В виду всего этого существует потенциальная опасность зависимости от порядка инициализации, т.к. вызов конструкторов из разных единиц компиляции неопределен. И неприятности могли бы быть в полный рост, если бы объект Kernel имел не static storage duration и/или производил бы обращение (инициализацию) к таблице процессов в конструкторе. Но ни того, ни другого там нет, таблица существует статически, в конструкторе объекта Kernel к ней обращений не производится, поэтому проблем нет. Но момент заслуживает самого серьезного внимания.

Тем не менее компилятор из состава VisualDSP++ v4.5 (для Blackfin'а) этот момент засек и выдает соответствующее предупреждение (даже не замечание). А вот IAR этого не замечает даже на уровне ремарок. Поэтому я бы рекомендовал сильно не надеяться на IAR'овские ремарки и придавать им большого значения. Имхо, самый правильный способ их использования - включать иногда, дабы посмотреть, что он там нашел, и, если момент застуживает внимания, пофиксить его. Но при постоянной работе выключать их совсем чтобы глаза не мозолили и не мешали наблюдать за более серъезными сообщениями.