Можно ли использовать указатель на член структуры для доступа к другому члену той же структуры?

Что делает вызов memcpy

Вопрос плохо поставлен. Давайте сначала посмотрим на код:

char repr[offsetof(struct first_member_padded_t, b)] = //some value
memcpy(repr, &a, sizeof(a));
memcpy(&(s.a), repr, sizeof(repr));

Сначала обратите внимание, что repr инициализирован, поэтому всем элементам в нем присваиваются значения.

Первый memcpy в порядке - он копирует байты из a в repr.

Если бы второй memcpy был memcpy(&s, repr, sizeof repr);, он скопировал бы байты из repr в s. Это приведет к записи байтов в s.a и, из-за размера repr, в любое заполнение между s.a и s.b. Согласно C 2018 6.5 7 и другим частям стандарта разрешен доступ к байтам объекта (а «доступ» означает как чтение, так и запись согласно 3.1 1). Таким образом, эта копия в s в порядке, и в результате s.a принимает то же значение, что и a.

Однако memcpy использует &(s.a), а не &s. Он использует адрес s.a, а не адрес s. Мы знаем, что преобразование s.a в указатель на тип символа позволит нам получить доступ к байтам s.a (6,5 7 и более) (и передача его в memcpy имеет тот же эффект, что и такое преобразование, поскольку memcpy указывается, чтобы иметь эффект копирования байтов), но неясно, позволяет ли нам получить доступ к другим байтам в s. Другими словами, у нас есть вопрос, можем ли мы использовать &s.a для доступа к байтам, отличным от тех, что указаны в s.a.

6.7.2.1 15 говорит нам, что если указатель на первый член структуры «соответствующим образом преобразован», результат указывает на структуру. Итак, если мы преобразовали &s.a в указатель на struct first_member_padding_t, он будет указывать на s, и мы определенно можем использовать указатель на s для доступа ко всем байтам в s. Таким образом, это также будет хорошо определено:

memcpy((struct first_member_padding t *) &s.a, repr, sizeof repr);

Однако memcpy(&s.a, repr, sizeof repr); преобразует только &s.a в void * (поскольку memcpy объявлен как принимающий void *, поэтому &s.a автоматически преобразуется во время вызова функции), а не в указатель на тип структуры. Это подходящее преобразование? Обратите внимание, что если бы мы сделали memcpy(&s, repr, sizeof repr);, он преобразовал бы &s в void *. 6.2.5 28 сообщает нам, что указатель на void имеет то же представление, что и указатель на символьный тип. Итак, рассмотрим эти два утверждения:

memcpy(&s.a, repr, sizeof repr);
memcpy(&s,   repr, sizeof repr);

Оба этих оператора передают void * в memcpy, и эти два void * имеют то же представление, что и друг друга, и указывают на один и тот же байт. Теперь мы можем интерпретировать стандарт педантично и строго так, чтобы они отличались тем, что последний может использоваться для доступа ко всем байтам s, а первый - нет. Тогда это странно, что у нас есть два обязательно идентичных указателя, которые ведут себя по-разному.

Такая строгая интерпретация стандарта C кажется возможной теоретически - разница между указателями могла возникнуть во время оптимизации, а не в фактической реализации memcpy, - но я не знаю ни одного компилятора, который бы это сделал. Обратите внимание, что такая интерпретация противоречит разделу 6.2 стандарта, в котором говорится о типах и представлениях. Интерпретация стандарта таким образом, что (void *) &s.a и (void *) &s ведут себя по-разному, означает, что две вещи с одним и тем же значением и типом могут вести себя по-разному, что означает, что значение состоит из чего-то большего, чем его значение и тип, что, похоже, не является целью 6.2 или стандарт в целом.

Type-Punning

В вопросе говорится:

Я пытаюсь понять, как работает каламбур, когда дело доходит до сохранения значения в члене структуры или объединения.

Это не каламбур, как обычно используется этот термин. Технически код обращается к s.a, используя lvalue другого типа, чем его определение (потому что он использует memcpy, который определен для копирования, как если бы с символьным типом, в то время как определенный тип - int), но байты происходят из int и являются копируется без изменений, и такое копирование байтов объекта обычно рассматривается как механическая процедура; это делается для создания копии, а не для переинтерпретации байтов в новый тип. «Типаж» обычно относится к использованию разных lvalue с целью переинтерпретации значения, например записи unsigned int и чтения float.

В любом случае, каламбур на самом деле не является предметом вопроса.

Ценности в членах

Заголовок спрашивает:

Какие значения мы можем хранить в членах структуры или объединения?

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

Padding принимает неуказанные значения

Вопрос цитирует стандарт:

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

и говорит:

Поэтому я интерпретировал это так, как будто у нас есть объект для хранения в члене, так что размер объекта равен sizeof(declared_type_of_the_member) + padding байты, связанные с заполнением, будут иметь неопределенное значение ...

Цитируемый текст в стандарте означает, что если байты заполнения в s были установлены на некоторые значения, как в случае с memcpy, а затем мы выполняем s.a = something;, то байты заполнения больше не требуются для хранения своих предыдущих значений.

Код в вопросе исследует другую ситуацию. Код memcpy(&(s.a), repr, sizeof(repr)); не сохраняет значение в элементе структуры в смысле, обозначенном в 6.2.6.1 6. Он не сохраняется ни в одном из элементов s.a или s.b. Это копирование байтов в, что отличается от того, что обсуждается в 6.2.6.1.

6.2.6.1 6 означает, что, например, если мы выполним этот код:

char repr[sizeof s] = { 0 };
memcpy(&s, repr, sizeof s); // Set all the bytes of s to known values.
s.a = 0; // Store a value in a member.
memcpy(repr, &s, sizeof s); // Get all the bytes of s to examine them.
for (size_t i = sizeof s.a; i < offsetof(struct first_member_padding_t, b); ++i)
    printf("Byte %zu = %d.\n", i, repr[i]);

тогда не обязательно, чтобы все нули были напечатаны - байты в заполнении могли измениться.

Во многих реализациях языка C Standard был написан для описания, попытка записать N-байтовый объект в структуре или объединении может повлиять на значение не более N байтов в структуре или объединении. С другой стороны, на платформе, которая поддерживает 8-битные и 32-битные хранилища, но не 16-битные хранилища, если кто-то объявил такой тип, как:

struct S { uint32_t x; uint16_t y;} *s;

а затем выполнили s->y = 23;, не заботясь о том, что произошло с двумя байтами, следующими за y, было бы быстрее выполнить 32-битное сохранение в y, слепо перезаписав два следующих за ним байта, чем выполнить пару 8-битных записей для обновления верхняя и нижняя половины y. Авторы Стандарта не хотели запрещать такое обращение.

Было бы полезно, если бы в стандарт были включены средства, с помощью которых реализации могли бы указывать, могут ли записи в элементы структуры или объединения нарушить память за их пределами, а программы, которые были бы нарушены таким нарушением, могли бы отказаться от выполнения в реализациях, где это могло произойти. Авторы Стандарта, однако, вероятно, ожидали, что программисты, которые будут заинтересованы в таких деталях, будут знать, на каком оборудовании должна работать их программа, и, следовательно, будут знать, будут ли такие нарушения памяти проблемой для такого оборудования.

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

Как сказал @ user694733, в случае заполнения между s.a и s.b, memcpy() обращается к области памяти, к которой не может получить доступ &a:

int a = 1;
int b;
b = *((char *)&a + sizeof(int));

Это неопределенное поведение, и в основном это то, что происходит внутри memcpy().