Скорее всего был локальный глюк какой-то конкретной версии mspgcc. Хотя принудительная упаковка - дело несложное, можно и её добавить, для пущей уверенности.


Нет, ничего из этого не увеличивает размер структуры. Проверил и с #pragma pack(x), и с -fpack-struct=x (x={4,8,16,32}), и с ними обоими одновременно.
До кучи проверил __attribute__ ((packed)) и __attribute__ ((aligned (x))) для типа.
Размер структуры равен 2, как я не извращался
Единственный вариант, который изменил размер, был вот такой:

Но этот вариант не страшен, потому что явно указывать alignment там, где он не нужен, мы не будем.


А, вон оно что! Теперь понял

Приведение типов - не хак. А осознанная необходимость. Я не с дырами борюсь, их у меня нет. А хочу писать не только 8-битовыми словами, но и 16-битовыми, 32-битовыми. Cortex-M это позволяет делать, начиная с любого адреса. Тем более, регистры микроконтроллера (или контроллера ЖКИ, который использую) и так выровнены по адресам.
Приведение типов указателя - обычное дело.

А теперь попробуйте проверить на такой структуре:

Вообще то компиляторы упаковывают структуры не от их [компилятора] большого желания, а от требования выполнить ограничения по выравниванию для полей этих самых структур. Так что, если у вас в структуре нет полей с требованиями по выравниванию (например у вас там все char) - то ничего выравниваться и не будет. А вот если есть - то перед этим полем может появится дыра, и вся структура в целом получит ограничение по выравниванию, как для этого поля (что в свою очередь может добавить дыру и в конце структуры)
Например (предполагаю требования по выравниванию на размер поля):

лишнее

А сколько воплей у народа по поводу невыровненного доступа на AT91** например! Там не особо позволяет 7tdmi.


Оно уже для другого: читаем программу и если чего-то надо добавить, сразу видим, сколько бит осталось.

Да, но речь шла о структурах, уже имеющих вручную сформированные отступы, типа такой:

Такие структуры используются, в частности, в заголовочных файлах от ST для описания периферии процессоров STM32. И меня интересует вопрос, могут ли такие структуры при каких-либо условиях перестать соответствовать описываемой ими периферии.
Пока получается, что всё нормально, соответствуют при любых ключах компиляции. (Ну, кроме непонятного случая, описанного MrYuran-ом)

Да, точно. Просчитался

Раз тут пошли "страшные истории"...
pragma pack(n) надо обязательно закрывать pragma pack()
При включении заголовка с незакрытой прагмой такие интересные косяки проявляются - все структуры в одном модуле сами собой "упаковываются", а в другом - остаются неупакованными, в зависимости от последовательности #include.

Пример для наглядности:


Так вот, A и B получились РАЗНЫЕ, хотя этого вряд-ли кто-то добивался :-)
Короче, плохая это прагма, не ленитесь писать атрибуты для каждой структуры.

Там, я так понял, ещё битовые поля были в подструктурах ioregister_t.
Что-то могло и на этом набежать.
Скажем,
структура flags2_t займёт 2*sizeof(unsigned), а не один байт. Причём никакие pack не помогут.

а если есть некая структура


и указатель

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

в каком именно месте и какие прагмы должны стоять чтобы p->c = 0xABCD1234; нормально работало всегда и везде?
или так лучше вообще не делать, а данные просто макросами по байтам по смещениям вытаскивать чтобы ни от платформы ни от компилятора не зависеть?

Наверное.
Ну а в результате, какой будет вывод? Можно безбоязненно пользоваться структурами от ST? Или ждать, когда _Pasha сделает базу данных?

Если программируем аппаратные средства микроконтроллеров STM32xxx, то используются не структуры, а указатели на типы структур, расположенные по фиксированным адресам.
Если просто пользуемся структурами, подобными предложенным ST, то не все ли равно, как упакованы данные? Куда записали, оттуда и прочитаем.

Какая нафиг разница? Если структура вдруг разъедется, то мы промахнёмся мимо нужного регистра и по указателю

Как же она разъедется, если указателю передан конкретный адрес! А дыры зарезервированы неиспользуемыми переменными.
P.S. Мы же ее (структуру) уже разъехали разъездили раскатали растянули.