"А с точки зрения голых Сей результат должен быть одинаковый."
кто такое сказал ? Ссылку плиз

При чем тут array? тут даже болише написано:
Word alignment (2-byte)
When word alignment is on, ..... char and unsigned char variables and fields can be placed at _any_ address

ну а вот теперь сделайте из этих variables ARRAY - на каждый элемент будете allign писать ?? Мы говорили про ARRRAY, не надо проблемы половой жизни сусликов в условиях крайнего Севера сюда приплюсовывать уходить от темы

А почему нет то?
Пойдём от противного! Где написано что разименованный указатель на элемент структуры не обязательно равен этому элементу структуры?

да и на x86 или без __attribute__ ((__packed__)) результат вывода циклов будет одинаковый.

ладно, возможно тут и промахнулся, и тем не менее к нашим баранам вернемся, массивам то есть

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

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

так... еще лучше.. кто глубже копнет :-D

DASM полностью прав!!! НЕ МОЖЕТ компилятор положить массив в памяти с дырками! Это противоречит всем законам языка. Я имею полное право сделать так:


Кто покажет мне (и DASM'у) хоть один компилятор, у которого эти три варианта будут не одинаковы???

Хочу сказать отдельное спасибо Alex03 за правильное предупреждение, т.к. доступ через указатель к переменной, не выровненной по умолчанию на архитектуре АРМ может работать некорректно. Я с этим еще не сталкивался, но словив такой глюк, можно долго проблемы разгребать

Как раз не ухожу, а наоборот: если уж при "Word alignment" компилятор будет "char variables and fields can be placed at _any_ address", то о каких дырах в массиве может идти речь.
(но это конкретный компилятор, допускаю, что есть специфические, может для DSP каких, где компилятору "удасться" сделать дыры, но я таких не знаю).

Угу,
Мне вот интересно что выдаёт первый цикл из моего примера на других компиляторах?
Кому не лень попробуйте на всяких IAR/Keil/RVDS? Только упаковку (например pragm pack(1) вместо __attribute__ ((__packed__))) надо подправить чтобы sizeof(test_struct_t)=5 было.

Интуиция мне говорит что возможно не все компиллеры такие разборчивые в этом плане как GCC.

Блин, сразу видно - DASM вернулся на форум. Ж) Из ничего флейма на 3 странички. С возвращением! Ж))

Проверил на ИАР 4.40а. На строки


ругается так:
Warning[Pa039]: use of address of unaligned structure member

При работе, первый цикл проходит как положено, а во втором из printf вываливается в обработчик ABORT DATA. Почему тогда в первом случае работает я не понимаю

да вы доки читайте ! тама написано, что это не рулез и так делать и ничего вам не гарантируется !

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