Вложенные структуры и строгие псевдонимы в c

Строгие правила псевдонимов — это два указателя разных типов, ссылающихся на одно и то же место в памяти (ISO /IEC9899/TC2). Хотя в вашем примере адрес object_t object переинтерпретируется как адрес person_t, он не ссылается на расположение памяти внутри object_t через переинтерпретированный указатель, поскольку age расположен за границей object_t. Поскольку ячейки памяти, на которые ссылаются указатели, не совпадают, я бы сказал, что это не нарушает строгого правила псевдонимов. FWIW, gcc -fstrict-aliasing -Wstrict-aliasing=2 -O3 -std=c99, похоже, согласен с этой оценкой и не выдает предупреждения.

Однако этого недостаточно, чтобы решить, что это законный код: в вашем примере предполагается, что адрес вложенной структуры такой же, как и у ее внешней структуры. Между прочим, это безопасное предположение в соответствии со стандартом C99:

6.7.2.1-13. Указатель на объект структуры, соответствующим образом преобразованный, указывает на его начальный элемент

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

http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

В качестве дополнения к принятому ответу, вот полная цитата из стандарта, в которой выделена важная часть, в которой пропущен другой ответ, и еще один:

6.7.2.1-13: Внутри структурного объекта члены, не являющиеся битовыми полями, и блоки, в которых находятся битовые поля, имеют адреса, возрастающие в порядке их объявления. Указатель на объект структуры, соответствующим образом преобразованный, указывает на его начальный элемент (или, если этот элемент является битовым полем, то на модуль, в котором он находится), и наоборот. Внутри объекта структуры может быть безымянный отступ, но не в его начале.

6.3.2.3-7: Указатель на объект или неполный тип может быть преобразован в указатель на другой объект или неполный тип. Если результирующий указатель неправильно выровнен для указанного типа, поведение не определено. В противном случае при обратном преобразовании результат будет равен исходному указателю. [...]

Я считаю ваш пример идеальным местом для указателя void:

int age(void *object) {

Почему? Потому что ваше очевидное намерение состоит в том, чтобы дать такой функции разные типы объектов, и она получает информацию в соответствии с закодированным типом. В вашей версии вам нужно приводить каждый раз, когда вы вызываете функцию: age((object_t*)person);. Компилятор не будет жаловаться, если вы дадите ему неправильный указатель, так что в любом случае безопасность типов не задействована. Затем вы также можете использовать указатель void и избегать приведения при вызове функции.

В качестве альтернативы вы можете, конечно, вызвать функцию с помощью age(&person->object). Каждый раз, когда вы звоните.

Строгие правила алиасинга ограничивают типы доступа к объекту (области памяти). В коде есть несколько мест, где может возникнуть правило: внутри age() и при вызове age().

В пределах age вам нужно рассмотреть object. ((person_t *)object) — это выражение lvalue, потому что оно имеет объектный тип и обозначает объект (область памяти). Однако ветвь достигается только в том случае, если object->type == PERSON, поэтому (предположительно) эффективным типом объекта является person_t*, поэтому приведение не нарушает строгое сглаживание. В частности, строгое сглаживание позволяет:

• тип, совместимый с эффективным типом объекта,

При вызове age() вы, вероятно, будете передавать object_t* или тип, производный от object_t: структуру, в которой object_t является первым членом. Это разрешено как:

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

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

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

struct tag  { int value;                };
struct obj1 { int tag;    Foo x; Bar y; };
struct obj2 { int tag;    Zoo z; Car w; };

typedef union object_
{
  struct tag;
  struct obj1;
  struct obj2;
} object_t;

Теперь вы можете безнаказанно пройти object_t * p и изучить p->tag.value, а затем получить доступ к нужному члену профсоюза.