Имею следующий кусок кода (упрощенно):

При компиляции получаю ошибку в строке
Если написать как

то ошибок нет. Как такое объяснить? И как такое побороть?
Так же sxModels участвует как составляющая другой структуры. У меня та структура не используется, но она описана в общем хэдере. После исправления на появляется ошибка в той структуре:

Компилятор IAR AVR 5.11, мк mega2560

sizeof() возвращает результат типа int. В вашем случае размер массива структур не может быть представлен типом int, который в AVR 16-битный. Когда вы делаете sizeof(sxModel) * 32 вы получаете переполнение уже в процессе вычисления операции умножения.

Нет, size_t, что в общем случае не int, а нечто достаточное для описания объекта максимального размера.

Вывод простой и неутешительный - ну не сможет данный контроллер работать(адресовать) с объектом такого размера.
Говорят , что на свете давно уже есть 32bit контроллеры, причем за меньшие деньги, нежели розовый Cadillac '68 Atmega256.

Да, чего-то меня переклинило при чтении стандарта:Почему-то я тут integer воспринял как int, не дочитав еще пару абзацев: Но вот странно - в unsigned int размер массива структур должен укладываться, а тут явно упоминается unsigned.

Тут ведь собственно размерность собственно самого size_t сугубо вторична - просто не может быть массив запрашиваемого ( неведомая CONST_M + 32*1300 ) размера и все. Причем все это через enum, который уже не unsigned int. Кроме того, хоть и написано в стандарте "is size_t, defined in <stddef.h>" size_t совершенно не обязательно должен определяться через другие типы - совершенно спокойно он может быть самостоятельным встроенным типом, что помнится сделано и, например, у IAR.

Если я правильно понимаю политику партии, там кроме size_t замешан ещё ptrdiff_t.
Объекты sxModels[0].model[0] и sxModels[31].model[1299] находятся внутри одного агрегата и взятие разности их адресов допустимо.
Причём как в виде &sxModels[0].model[0] - &sxModels[31].model[1299] (отрицательная) так и в виде &sxModels[31].model[1299] - &sxModels[0].model[0] (положительная). И она тоже не даёт размеру объекта вылезть за некоторые рамки.
Почему size_t при этом допускает больший размер, чем ptrdiff_t — не знаю.

p.s. даже если бы объекты были не байтовыми, (unisgned char*)&top_subobject - (unisgned char*)&bott_subobject дпустимо и должно дать число, представимое в ptrdiff_t