Может ли заполнение структуры безопасно использоваться кодом пользователя? - PullRequest
6 голосов
/ 06 января 2010

Предполагая, что у меня есть структура, подобная следующей:

struct Struct {
    char Char;
    int Int;
};

и sizeof( int ) больше единицы, и компилятор добавляет заполнение для переменной-члена Char - разрешено ли сгенерированному компилятором коду изменять значения байтов заполнения?

Я имею в виду, если я использую арифметику указателей и запишу некоторые данные в байты заполнения, окружающие переменную-член Char, а затем сделаю присваивание variable.Char =, возможно ли, что код, сгенерированный компилятором, также перезапишет некоторые байты заполнения

Ответы [ 4 ]

13 голосов
/ 06 января 2010

Что, если компилятор был достаточно умен, чтобы использовать слово write для сохранения символа? Ваши тщательно сохраненные данные будут потеряны. ; -)

10 голосов
/ 06 января 2010

Следующее предложение неверно : Нет, оно не будет перезаписывать байты заполнения. Но, вероятно, это не очень хорошая практика. Если вам это нужно, добавьте туда переменные-члены.

Я исследовал, основываясь на комментариях, указывающих ( правильно ), что я глуп:

Стандарт C имеет «Приложение J» с разделом J.1 Неопределенное поведение . Он говорит: «Значение байтов заполнения при хранении значений в структурах или объединениях». Это означает, что компилятор может генерировать любые инструкции, которые он хочет записать в структуру данных, что может позволить ему перезаписать заполнение после члена.

4 голосов
/ 06 января 2010

Вы, конечно, можете написать что-то там, и memset - экземпляр такой структуры сделает это. Тем не менее, небезопасно и никогда не стоит делать это . Однажды другой разработчик поместит #pragma куда-нибудь или добавит элемент в объявление структуры, и ваш код взорвется многими странными и причудливыми способами, которые могут занять много времени для отладки.

1 голос
/ 06 января 2010

Единственная причина сделать это - что-то вроде плагина, который злобно обманывает хост-приложение для хранения дополнительных данных.

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

...