Является ли поведение следующего шаблона доступа C union undefined?

Отчет о дефекте 283: Доступ к несуществующему члену профсоюза («набирать текст») покрывает это и сообщает нам, что существует неопределенное поведение, если есть представление ловушки.

В отчете о дефектах спрашивали:

In the paragraph corresponding to 6.5.2.3#5, C89 contained this sentence:

With one exception, if a member of a union object is accessed after a value has been stored in a different member of the object, the behavior is implementation-defined.

Associated with that sentence was this footnote:

The "byte orders" for scalar types are invisible to isolated programs that do not indulge in type punning (for example, by assigning to one member of a union and inspecting the storage by accessing another member that is an appropriately sixed array of character type), but must be accounted for when conforming to externally imposed storage layouts.

The only corresponding verbiage in C99 is 6.2.6.1#7:

When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values, but the value of the union object shall not thereby become a trap representation.

It is not perfectly clear that the C99 words have the same implications as the C89 words.

В отчет о дефектах добавлена ​​следующая сноска:

Attach a new footnote 78a to the words "named member" in 6.5.2.3#3:

78a If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.

C11 6.2.6.1 Общие сообщает нам:

Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.⁵⁰⁾Such a representation is called a trap representation.

Из 6.2.6.1 §7:

When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values.

Таким образом, значение plugh.i не будет указано после установки plugh.c.

Из сноски к 6.5.2.3 §3:

If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be a trap representation.

Это говорит о том, что каламбур специально разрешен (как вы утверждали в своем вопросе). Но это может привести к представлению ловушки, и в этом случае чтение значения имеет неопределенное поведение в соответствии с 6.2.6.1 §5:

Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined. 50) Such a representation is called a trap representation.

Если это не представление ловушки, кажется, что в стандарте нет ничего, что могло бы сделать это поведение undefined, потому что из 4 §3 мы получаем:

A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3.

C11 §6.2.6.1 p7 говорит:

When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values.

Итак, plugh.i не указан.

Другие ответы касаются основного вопроса о том, вызывает ли чтение plugh.i неопределенное поведение, когда plugh не был инициализирован и когда-либо был назначен только plugh.c. Вкратце: нет, если байты plugh.i не составляют представление прерывания во время чтения.

Но я хочу обратиться непосредственно к предварительному утверждению в вопросе:

Most C compilers nowadays will have sizeof(char) < sizeof(int), with sizeof(int) being either 2 or 4. That means that in these cases at most 50% or 25% of plugh.i will have been written to

Вопрос, похоже, предполагает, что присвоение значения plugh.c оставит нетронутыми те байты plugh, которые не соответствуют c, но стандарт никоим образом не поддерживает это предположение. Фактически, он прямо отрицает любую такую ​​гарантию, поскольку, как отмечали другие:

When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values.

(C2011, 6.2.6.1/7; курсив мой)

Хотя это не гарантирует, что неопределенные значения, принимаемые этими байтами, отличаются от их значений до назначения, он прямо предусматривает, что они могли быть такими. И вполне вероятно, что в некоторых реализациях они часто будут такими. Например, на платформе, которая поддерживает только запись размера слова в память или где такие записи более эффективны, чем записи размера байта, вполне вероятно, что назначения plugh.c реализованы с записью размера слова, без предварительной загрузки других байтов plugh.i, чтобы сохранить свои ценности.

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

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

struct c8 { uint32_t u; unsigned char arr[4]; };
union uc { uint32_t u; struct c8 dat; } uuc1,uuc2;

void wowzo(void)
{
  union uc u;
  u.u = 123;
  uuc1 = u;
  uuc2 = u;
}

Я думаю, ясно, что Стандарт не требует, чтобы байты в uuc1.dat.arr или uuc2.dat.arr содержали какое-либо конкретное значение, и что компилятору будет разрешено для каждого из четырех байтов i == 0..3 копировать uuc1.dat.arr[i] в uuc2.dat.arr[i], скопируйте uuc2.dat.arr[i] в uuc1.dat.arr[i] или запишите как uuc1.dat.arr[i], так и uuc2.dat.arr[i] с совпадающими значениями. Я не думаю, что ясно, намеревается ли Стандарт требовать, чтобы компилятор выбирал один из этих способов действий, а не просто оставлял эти байты удерживающими то, что они случайно содержат.

Очевидно, что код должен иметь поведение, определенное от корки до корки, если ничто никогда не наблюдает за содержимым uuc1.dat.arr или uuc2.dat.arr, и нет никаких оснований предполагать, что проверка этих массивов должна вызывать UB. Кроме того, не существует определенных средств, с помощью которых значение u.dat.arr могло бы изменяться между назначениями uuc1 и uuc2. Это предполагает, что uuc1.dat.arr и uuc2.dat.arr должны содержать совпадающие значения. С другой стороны, для некоторых типов программ сохранение явно бессмысленных данных в uuc1.dat.arr и / или uuc1.dat.arr редко служит какой-либо полезной цели. Я не думаю, что авторы Стандарта специально намеревались требовать таких хранилищ, но заявление о том, что байты принимают «неуказанные» значения, делает их необходимыми. Я бы ожидал, что такая поведенческая гарантия будет устаревшей, но я не знаю, что могло бы ее заменить.