Что-то я в последнее время много топиков развел, но все же....

В компиляторе REAL VIEW в KEIL, в соответствии с сишными стандартами, явно неинициализированные переменные по дефолту инициализируются нулями, но, напимер, в моем случае это очень неудобно.
У меня есть дополнение к некоторому массиву данных который храниется во флеше, которое должно быть инициализировано 0xFF-ми, но это дополнение в общем случае переменной длины, которая вычисляется в зависимости от длины массива данных. Тоесть сейчас я компилируюсь с одной длиной дополнения, а завтра эта длина может поменяться. И соответственно очень не хочется каждый раз руками изменять в коде количество 0xFF-ов, к тому же можно просто забыть про это, что вызовет ошибки...
Так вот, я копался в хелпах Кейла, но так и не нашел директивы, меняющей инициализацию по умолчанию... Может быть есть возможность делать инициализацию как-нибуть в автомате? Может макросы такие есть или всетаки директивы?

Не майтесь и не создавайте проблем себе - все, что должно-быть инициализировано явно, должно быть явно и инициализировано. Кроме того, как нечно хранящееся во Flash может быть "переменной" и инициализироваться.

В общем случае - категорически нет.

Ну это константа. Например так:




Пример упрощен, но суть примерно такая. в dummy 0xFF будет только первый байт, а остальные нулями. А хотелось бы чтобы какнибуть в автомате сделать весь dummy 0xFF.

Это все сводится к тому, чтобы выравнивать данные по адресам и по дленне до кратности 16 байтам.

Я понял, о чем шла речь.
Просто счел необходимым отметить, что к неициализированным переменным, которые потому и не инициализированные, что не инициализируются этот случай не имеет никакого отношения.
В данном случае Ваша переменная (или константа, если Вы прикажете разместить ее в CONST сегменте)
это вся структура целиком и инициализация хотя-бы одного элемента сразу всю стуктуру целиком делает инициализированной и приводит к ее размещению вне сегмента BSS. Неинициализированные Вами явно поля не могут иметь 'никакого' значения и по это причине действительно инициализируются 0. Но еще раз подчеркивую Вы имеете дело с инициализированной структурой, а отнюдь не с тем, что якобы в 'С' неициализированные данные обнуляются.
В подобных случаях придется явно инициализовать 0xFF при объявлении, а правильнее считать, что неиспользуемые элементы обнулены .
Для случая выравнивания все проще - эту проблему обычно решает #pragma data_alignment=
хотя насчет того, что мусор между структурами будет 0xff никаких гарантий быть не может.
Выводы - практически наверняка неудачно постороена система работы с вышеописанной стуктурой - поменяйте , дабы независеть от содержимого памяти ПОСЛЕ структуры.

Спасибо за разъяснения! Насчет структуры я подумаю. А прагмы такой в этом компиляторе RealView нету Есть другие, но они позволяют выравнивать только по 8 байт.

Очень странное ограничение. А Вы не ошибаетесь? Не позволяют - это одно, "не работают" - это другое и понятное, поскольку скорее всего сам сегмент в котором Вы данные размещаете выровенен всего на 8 байт - укажите ему выравнивание на 16.

Кстати, про выравнивание:
в версии 3.1 компилятора RV, что идет в комплекте с МДК3.11, корректно работает #pragma pack() - как в "IAR C/EC++ Compiler", "Borland C++Builder" или "Microsoft Visual C++".

В документации пока не отражено, но я потестировал, посмотрел листинги..
По ссылке косвенное подтверждение...
http://www.keil.com/forum/docs/thread9546.asp

Она все-равно нулями выравнивает, и похоже опять-таки только максимум по 8 байт

Не знаю как в RealView но в GCC, а точнее в LD достаточно записать в скрипте линкера что-то на подобие:

А C файле указать:


Сообщение отредактировал amw - Aug 23 2007, 17:15