Является ли неопределенным поведением вызов функции с указателями на разные элементы объединения в качестве аргументов?

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

Если мы просто обсуждаем псевдонимы членов объединения, то это было бы проще. В следующем коде:

u.i = 5;
u.l = 6;
printf("%d\n", u.i);

поведение не определено, поскольку эффективным типом u является long; то есть хранилище u содержит значение, которое было сохранено как long. Но доступ к этим байтам через lvalue типа int нарушает правила псевдонимов 6.5p7. Текст о неактивных членах союза, имеющих неуказанные значения, не применяется (IMO); правила псевдонимов превосходят это, и этот текст вступает в игру, когда правила псевдонимов не нарушаются, например, при доступе через lvalue символьного типа.

Если мы поменяем порядок первых двух строк выше, тогда программа будет четко определена.

Однако все меняется, когда доступ «спрятан» за указателями на функцию.

DR236 решает эту проблему с помощью двух примеров. Оба примера имеют check(), как в этом посте. Пример 1 malloc занимает немного памяти и передает h и k, указывающие на начало этого блока. В примере 2 есть союз, аналогичный этому посту.

Их вывод состоит в том, что пример 1 является «неразрешенным», а пример 2 — UB. Однако в этом превосходном сообщении в блоге указывается, что логика, используемая DR236, в достижении этих выводов непоследовательно. (Спасибо Тору Клингбергу за это).

В последней строке DR236 также говорится:

Обе программы вызывают неопределенное поведение, вызывая функцию f с указателями qi и qd, которые имеют разные типы, но обозначают одну и ту же область памяти. Переводчик имеет полное право изменить доступ к *qi и *qd по обычным правилам псевдонимов.

(очевидно, в противоречии с более ранним утверждением, что пример 1 не был решен).

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

Было высказано предположение, что правила псевдонимов позволяют компилятору сделать вывод, что int * и long * не могут получить доступ к одной и той же памяти. Однако примеры 1 и 2 этому категорически противоречат.

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

Тем не менее, я не вижу разницы между этим случаем и случаями примеров 1 и 2.

DR236 также говорит:

Общее понимание состоит в том, что объявление объединения должно быть видно в единице перевода.

что снова противоречит утверждению о том, что пример 2 является UB, потому что в примере 2 весь код находится в одной и той же единице перевода.

Мой вывод: мне кажется, что формулировка C99 указывает на то, что компилятору не следует разрешать переупорядочивать *h = 5; и *k = 6; в случае, если они перекрывают хранилище. Несмотря на то, что DR236 противоречит формулировке C99 и ничего не проясняет. Но чтение *h после этого должно привести к неопределенному поведению, поэтому компилятору разрешено генерировать вывод 5 или 6 или что-то еще.

По моему мнению, если вы измените check() на *k = 6; *h=5;, тогда должно быть четко определено, чтобы напечатать 5. Было бы интересно посмотреть, делает ли компилятор что-то еще в этом случае, а также обоснование компилятора, если он это делает.

Соответствующая цитата из стандарта - это соответствующие правила псевдонимов, которые нарушаются. Нарушение нормативного shall всегда приводит к Неопределенному поведению, поэтому все идет так:

6.5 Выражения §7
Доступ к хранимому значению объекта должен осуществляться только выражением lvalue, имеющим один из следующих типов:88)
— тип, совместимый с действующим типом объекта object,
— уточненная версия типа, совместимая с эффективным типом объекта,
— тип, который является подписанным или беззнаковым типом, соответствующим эффективному типу объекта,
— тип, который — тип со знаком или без знака, соответствующий уточненной версии эффективного типа объекта,
— тип агрегата или объединения, который включает в себя один из вышеупомянутых типов среди своих членов (включая, рекурсивно, член подагрегата или содержащийся в нем тип). union), или
— тип символа.

В то время как main() использует union, check() нет.

Я скомпилировал ваш код с параметрами -O1 и -O2 и запустил сеанс gdb, вот результат:

(gdb) r
Starting program: /home/sheri/test 
Breakpoint 1, main () at test.c:17
17  {
(gdb) s
19          check(&u.i, &u.l);
(gdb) p u
$1 = <optimized out>
(gdb) p u.i
$2 = <optimized out>
(gdb) p u.l
$3 = <optimized out>`

Я не эксперт по gdb, но вот что следует отметить. 1. союза нет в стеке, но он хранится в регистре, и поэтому он печатает, когда вы его печатаете, или это i или l

Я разобрал исполняемый файл и посмотрел на main, и вот что я нашел: 0000000000400440 :

400440: 48 83 ec 08             sub    $0x8,%rsp
400444: ba 06 00 00 00          mov    $0x6,%edx
400449: be 3c 06 40 00          mov    $0x40063c,%esi
40044e: bf 01 00 00 00          mov    $0x1,%edi
400453: 31 c0                   xor    %eax,%eax
400455: e8 d6 ff ff ff          callq  400430 <__printf_chk@plt>

Таким образом, в строке 2 компилятор поместил 0x6 в регистр %edx напрямую и не создал проверку функции в первую очередь, так как уже понял, что значение, передаваемое в printf, всегда будет равно 6.

Может быть, вам стоит попробовать то же самое и посмотреть, какой результат вы получили на своей машине.

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

Стандарт C99 хотел позволить компиляторам быть более агрессивными с псевдонимами на основе типов, несмотря на тот факт, что его квалификатор «restrict» устраняет большую часть необходимости в этом, но не мог делать вид, что приведенный выше код недопустим, поэтому он добавляет требование, согласно которому, если компилятор видит, что два указателя могут быть членами одного и того же объединения, он должен допускать такую ​​возможность. В отсутствие оптимизации всей программы это позволило бы сделать большинство программ C89 совместимыми с C99, обеспечив видимость подходящих определений типов объединения во всех функциях, которые могут видеть оба типа указателей. Чтобы ваш код был действителен в соответствии с C99, вам нужно переместить объявление типа объединения над функцией, которая получает два указателя. Это по-прежнему не заставит код работать для gcc, потому что авторы gcc не хотят, чтобы такие детали, как правильное стандартное поведение, мешали созданию «эффективного» кода.

Взятие адресов абсолютно нормально.

Что не так: Чтение объекта с использованием типа, отличного от того, который использовался для его записи. Таким образом, после записи в int* чтение long* является неопределенным поведением и наоборот. Запись в int*, затем запись в long* и т. д. определяется поведением (теперь объединение имеет член long с определенным значением).