Да ладно вам стращать Современные компиляторы отлично оптимизируют конструкции вида

Думаю, что код, сгенерированный компилятором в вашем варианте и в этом будет эквивалентен. Зато этот вариант понятнее, к тому же он переносим.

Интересно. Когда подведет еще раз - выложите сюда, вероятнее всего вы просто не умеете ее готовить.

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


Для упрощения примера я вставил сразу gcc'шный вариант, но в боевом это макросы в зависимости от платформы. Так что упакованная структура так же переносима.

Возможно. Мне тяжело сейчас предоставить "живой" пример - дело было два-три года назад.
Помню, что ошибка проявлялась при совместном использовании оптимизации по размеру и LinkTimeOptimization (Os и flto).
Проект был по CooCox и они только добавили опцию LTO у себя в настройках компиляции.
Обошел ее используя не библиотечную реализацию:

"помогало" именно создание volatile'ной переменной и дальнейшая работа с ней.
в противном случае (при использовании аргументной переменной n) бесконечно висел в while - уменьшение переменной не происходило.
причем висело не в моем коде, а внутри функций freertos (тогда то ли 6, то ли 7 версии).
понимаю, что это все выглядит как рассказ про йети, но...

Удалил, попутал со знаковым переполнением.