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

Если посмотрите на код, на который выдаются эти ремарки, то увидите, что это глубоко платформенно- и компиляторо-зависимые вещи, связанные с переключением указателя стека на стек прерываний:



Т.е. никуда этот код переноситься не будет. Да и само наличие страшных reinterpret_cast указывает на потенциально опасное место, но в данном случае иного пути достчить цели как-то не видно.

Что касается замечания Pa091, то для меня это тоже загадка, что тут компилятору не понравилось. Тем более, что предыщущая строка по сути представляет собой точно такое же выражение, но на него ругани нет.

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

... еще можно сделать дифф и положить в Tracker на sf.net, в раздел Patches
.

PS:
IgorKossak, svn в данном проекте используется?

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


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

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

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


Так обычно и делаю. Вот только лишняя возня иногда напрягает.