Строго соответствует ли такое использование профсоюзов?

Я считаю, что ваш код соответствует требованиям, и есть недостаток в -fstrict-aliasing режиме GCC и Clang.

Я не могу найти нужную часть стандарта C, но та же проблема возникает при компиляции вашего кода в режиме C ++ для меня, и я нашел соответствующие отрывки стандарта C ++.

В стандарте C ++ [class.union] / 5 определяет, что происходит, когда оператор = используется в выражении доступа к объединению. Стандарт C ++ гласит, что когда объединение участвует в выражении доступа к члену встроенного оператора =, активный член объединения изменяется на член, участвующий в выражении (если тип имеет тривиальный конструктор, но поскольку это это код на C, у него есть тривиальный конструктор).

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

Даже если я использую размещение new для явного изменения того, какой член объединения активен, что должно быть подсказкой компилятору, что активный член изменился, GCC все равно генерирует код, который выводит 4321.

Это похоже на ошибку с GCC и Clang, предполагающую, что переключение активного члена объединения не может здесь произойти, потому что они не распознают возможность того, что p1, p2 и p3 все указывают на один и тот же объект.

GCC и Clang (и почти любой другой компилятор) поддерживают расширение C / C ++, где вы можете читать неактивный член объединения (получая в результате любое потенциально мусорное значение), но только если вы делаете этот доступ в доступе к члену выражение с участием союза. Если бы v1 не был активным членом, read_s1x не было бы определено поведение в соответствии с этим правилом, зависящим от реализации, потому что объединение не входит в выражение доступа к члену. Но поскольку v1 является активным участником, это не имеет значения.

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

При строгой интерпретации стандарта этот код может не соответствовать. Сосредоточимся на тексте известного §6.5p7:

Сохраненное значение объекта должно быть доступно только выражению lvalue, которое имеет один из следующих типов:
- тип, совместимый с эффективным типом объекта,
- квалифицированная версия типа, совместимого с эффективным тип объекта,
- тип со знаком или без знака, соответствующий действующему типу объекта,
- тип со знаком или без знака, соответствующий квалифицированной версии действующего типа объекта. объект,
- тип агрегата или объединения, который включает в себя один из вышеупомянутых типов среди своих членов (включая, рекурсивно, член субагрегатного или содержащегося объединения), или
- a тип персонажа.

(курсив мой)

Ваши функции read_s1x() и write_s2x() делают противоположное тому, что я выделил жирным шрифтом выше в контексте всего вашего кода. Имея только этот абзац, вы можете сделать вывод, что это недопустимо: указателю на union s1s2 будет разрешено использовать псевдоним указателя на struct s1, но не наоборот.

Такая интерпретация, конечно, будет означать, что код должен работать так, как задумано, если вы «встроите» эти функции вручную в свой test(). Это действительно так, с gcc 6.2 для i686-w64-mingw32.

Добавляем два аргумента в пользу строгой интерпретации, представленной выше:

• Хотя всегда разрешено использовать псевдоним любого указателя с помощью char *, массив символов не может быть псевдонимом какого-либо другого типа.

• # P8 #

  # P9 #

  # P10 #

Я не читал стандарт, но играть с указателями в режиме строгого псевдонима (т.е. использовать -fstrict-alising) опасно. См. онлайн-документ gcc:

Обратите особое внимание на такой код:

union a_union {
  int i;
  double d;
};

int f() {
  union a_union t;
  t.d = 3.0;
  return t.i;
}

Распространена практика чтения из другого члена союза, чем тот, которому в последний раз писали (называемый type-punning). Даже с -fstrict-aliasing допускается перенаправление типов при условии, что доступ к памяти осуществляется через тип объединения. Итак, приведенный выше код работает так, как ожидалось. См. Перечисления объединений структур и реализация битовых полей. Однако этот код не может:

int f() {
   union a_union t;
   int* ip;
   t.d = 3.0;
   ip = &t.i;
   return *ip;
}

Точно так же доступ путем взятия адреса, приведения результирующего указателя и разыменования результата имеет неопределенное поведение, даже если при приведении используется тип объединения, например:

int f() {
  double d = 3.0;
  return ((union a_union *) &d)->i;
}

Опция -fstrict-aliasing включается на уровнях -O2, -O3, -Os.

Нашли что-нибудь похожее во втором примере, да?

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

  sub rsp, 8
  mov esi, 4321
  mov edi, OFFSET FLAT:.LC0
  xor eax, eax
  call printf
  xor eax, eax
  add rsp, 8
  ret

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

int test(union s1s2 *p1, union s1s2 *p2, volatile union s1s2 *p3)
/* ....*/

main:
  sub rsp, 8
  mov esi, 1234
  mov edi, OFFSET FLAT:.LC0
  xor eax, eax
  call printf
  xor eax, eax
  add rsp, 8
  ret

это довольно тривиальный тест, только искусственно усложненный.