C - поведение преобразования между двумя указателями

Интерпретация Б верна. Стандарт говорит об указателе на объект, а не о самом объекте. «Результирующий указатель» относится к результату приведения, а приведение не создает lvalue, поэтому оно относится к значению указателя после приведения.

Взяв код из вашего примера, предположим, что int должен быть выровнен по 4-байтовой границе, т. е. его адрес должен быть кратным 4. Если адрес buf равен 0x1001, то преобразование этого адреса в int * недопустимо, поскольку значение указателя равно не выровнено должным образом. Если адрес buf равен 0x1000, то его преобразование в int * допустимо.

Обновлять:

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

Определенный вами массив содержит объекты типа char. Преобразуя адрес в другой тип и впоследствии разыменовывая преобразованный тип, вы получаете доступ к объектам одного типа как к объектам другого типа. Это не разрешено стандартом C.

Хотя термин «строгий псевдоним» не используется в стандарте, концепция описана в параграфах 6 и 7 раздела 6.5:

6 Эффективным типом объекта для доступа к его хранимому значению является объявленный тип объекта, если таковой имеется. значение сохраняется в объекте, не имеющем объявленного типа, через lvalue, имеющее тип, отличный от символьного типа, то тип lvalue становится эффективным типом объекта для этого доступа и для последующих обращений, которые не изменяют сохраненное значение. Если значение копируется в объект, не имеющий объявленного типа, с помощью memcpy или memmove, или копируется как массив символов, то эффективный тип измененного объекта для этого доступа и для последующие обращения, которые не изменяют значение, являются эффективным типом объекта, из которого копируется значение, если оно имеется. Для всех другие обращения к объекту, не имеющему объявленного типа, эффективный тип объекта - это просто тип lvalue, используемый для доступ.

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

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

...

87) Размещенные объекты не имеют объявленного типа.

88) Цель этого списка состоит в том, чтобы указать те обстоятельства, при которых объект может иметь или не иметь псевдоним.

В вашем примере вы пишете unsigned long и double поверх char объектов. Ни один из этих типов не удовлетворяет условиям параграфа 7.

Кроме того, арифметика указателя здесь недействительна:

 *(((double *) buf) + 2) = 1.618;

Поскольку вы рассматриваете buf как массив double, когда это не так. По крайней мере, вам нужно будет выполнить необходимые арифметические действия непосредственно над buf и привести результат в конце.

Так почему же это проблема для массива char, а не для буфера, возвращаемого malloc? Потому что память, возвращаемая из malloc, не имеет эффективного типа, пока вы не сохраните что-то в ней, что и описано в параграфе 6 и сноске 87.

Итак, со строгой точки зрения стандарта то, что вы делаете, является неопределенным поведением. Но в зависимости от вашего компилятора вы можете отключить строгие псевдонимы, чтобы это сработало. Если вы используете gcc, вам нужно передать флаг -fno-strict-aliasing

Стандарт не требует, чтобы реализации учитывали возможность того, что код когда-либо обнаружит значение в T*, которое не выровнено для типа T. В clang, например, при нацеливании на платформы, чьи «крупные» инструкции загрузки/сохранения не поддерживают невыровненный доступ. , преобразование указателя в тип, выравнивание которого он не удовлетворяет, а затем использование memcpy для него может привести к тому, что компилятор сгенерирует код, который завершится ошибкой, если указатель не выровнен, даже если сам memcpy в противном случае не наложил бы никаких требований к выравниванию.

Например, при нацеливании на ARM Cortex-M0 или Cortex-M3 с учетом:

void test1(long long *dest, long long *src)
{
    memcpy(dest, src, sizeof (long long));
}
void test2(char *dest, char *src)
{
    memcpy(dest, src, sizeof (long long));
}
void test3(long long *dest, long long *src)
{
    *dest = *src;
}

clang сгенерирует код как для test1, так и для test3, который потерпит неудачу, если src или dest не будут выровнены, но для test2 он сгенерирует код, который больше и медленнее, но который будет поддерживать произвольное выравнивание операндов источника и назначения.

Конечно, даже при clang преобразование невыровненного указателя в long long* само по себе обычно не вызывает ничего странного, но тот факт, что такое преобразование приведет к созданию UB, освобождает компилятор от какой-либо ответственности за обработку. случай невыровненного указателя в test1.