C неопределенным поведением. Строгое правило алиасинга или неправильное выравнивание?

Код действительно нарушает строгое правило псевдонима. Однако существует не только нарушение псевдонима, и сбой не происходит из-за нарушения псевдонима. Это происходит из-за того, что указатель unsigned short неправильно выровнен; даже само преобразование указателя не определено, если результат не выровнен должным образом.

C11 (черновик n1570), приложение J.2:

1 Поведение не определено в следующих случаях:

....

• Преобразование между двумя типами указателей дает результат, который неправильно выровнен (6.3.2.3).

С 6.3.2.3p7 говоря

[...] Если результирующий указатель неправильно выровнен [68] для указанного типа, поведение не определено. [...]

unsigned short в вашей реализации (x86-32 и x86-64) требуется выравнивание 2, которое вы можете протестировать с помощью

_Static_assert(_Alignof(unsigned short) == 2, "alignof(unsigned short) == 2");

Однако вы заставляете u16 *key2 указывать на невыровненный адрес:

u16 *key2 = (u16 *) (keyc + 1);  // we've already got undefined behaviour *here*!

Бесчисленное количество программистов настаивают на том, что невыровненный доступ гарантированно работает на практике на x86-32 и x86-64 везде, и на практике не возникнет никаких проблем - ну, все они ошибаются.

Обычно компилятор замечает, что

for (size_t i = 0; i < len; ++i)
     hash += key2[i];

можно более эффективно выполнять с помощью инструкций SIMD, если они соответствующим образом выровнены. Значения загружаются в регистры SSE с использованием _ 7_, что требует, чтобы аргумент был выровнен по 16 байтам:

Если исходный или целевой операнд является операндом памяти, этот операнд должен быть выровнен по 16-байтовой границе, иначе будет сгенерировано исключение общей защиты (#GP).

В случаях, когда указатель не выровнен надлежащим образом в начале, компилятор сгенерирует код, который суммирует первые 1-7 беззнаковых коротких замыканий один за другим, пока указатель не выровняется по 16 байтам.

Конечно, если вы начнете с указателя, который указывает на нечетный адрес, даже если не сложить 7 умножить на 2, то получится адрес, выровненный по 16 байтам. Конечно, компилятор даже не сгенерирует код, который обнаружит этот случай, поскольку «поведение не определено, если преобразование между двумя типами указателей дает результат, который неправильно выровнен» - и игнорирует ситуация полностью с непредсказуемыми результатами, что означает, что операнд MOVDQA не будет правильно выровнен, что приведет к затем завершите работу программы.

Легко доказать, что это может происходить даже без нарушения каких-либо строгих правил псевдонима. Рассмотрим следующую программу, которая состоит из 2 единиц перевода (если и f, и вызывающая сторона помещены в одну единицу перевода, мой GCC достаточно умен, чтобы заметить, что мы < em>, используя здесь упакованную структуру, и не генерирует код с MOVDQA):

единица перевода 1:

#include <stdlib.h>
#include <stdint.h>

size_t f(uint16_t *keyc, size_t len)
{
    size_t hash = len;
    len = len / 2;

    for (size_t i = 0; i < len; ++i)
        hash += keyc[i];
    return hash;
}

единица перевода 2

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <inttypes.h>

size_t f(uint16_t *keyc, size_t len);

struct mystruct {
    uint8_t padding;
    uint16_t contents[100];
} __attribute__ ((packed));

int main(void)
{
    struct mystruct s;
    size_t len;

    srand(time(NULL));
    scanf("%zu", &len);

    char *initializer = (char *)s.contents;
    for (size_t i = 0; i < len; i++)
       initializer[i] = rand();

    printf("out %zu\n", f(s.contents, len));
}

Теперь скомпилируйте и свяжите их вместе:

% gcc -O3 unit1.c unit2.c
% ./a.out
25
zsh: segmentation fault (core dumped)  ./a.out

Обратите внимание, что здесь нет нарушения псевдонима. Единственная проблема - это невыровненный uint16_t *keyc.

При -fsanitize=undefined выдается следующая ошибка:

unit1.c:10:21: runtime error: load of misaligned address 0x7ffefc2d54f1 for type 'uint16_t', which requires 2 byte alignment
0x7ffefc2d54f1: note: pointer points here
 00 00 00  01 4e 02 c4 e9 dd b9 00  83 d9 1f 35 0e 46 0f 59  85 9b a4 d7 26 95 94 06  15 bb ca b3 c7
              ^ 

Допустимо присвоить указателю на объект псевдоним указателя на char, а затем выполнить итерацию всех байтов исходного объекта.

Когда указатель на char фактически указывает на объект (был получен с помощью предыдущей операции), допустимо преобразование обратно в указатель на исходный тип, а стандарт требует, чтобы вы вернули исходное значение.

Но преобразование произвольного указателя на char в указатель на объект и разыменование полученного указателя нарушает правило строгого псевдонима и вызывает неопределенное поведение.

Итак, в вашем коде следующая строка - UB:

const u16 *key2 = (const u16 *) (keyc + 1); 
// keyc + 1 did not originally pointed to a u16: UB

Чтобы предоставить дополнительную информацию и распространенные ошибки отличного ответа от @Antti Haapala:

TL; DR: доступ к невыровненным данным - это неопределенное поведение (UB) в C / C ++. Невыровненные данные - это данные по адресу (также известному как значение указателя), который не делится равномерно на его выравнивание (обычно это его размер). В (псевдо) коде: bool isAligned(T* ptr){ return (ptr % alignof(T)) == 0; }

Эта проблема часто возникает при анализе форматов файлов или данных, отправляемых по сети: у вас есть плотно упакованная структура с разными типами данных. Примером может служить такой протокол: struct Packet{ uint16_t len; int32_t data[]; }; (Читается как: длина 16 бит, за которой следует len, умноженное на 32-битное int в качестве значения). Теперь вы могли:

char* raw = receiveData();
int32_t sum = 0;
uint16_t len = *((uint16_t*)raw);
int32_t* data = (int32_t*)(raw2 + 2);
for(size_t i=0; i<len; ++i) sum += data[i];

Это не работает! Если вы предполагаете, что raw выровнен (по вашему мнению, вы можете установить raw = 0, который выровнен по любому размеру как 0 % n == 0 для всех n), тогда data невозможно выровнять (при условии, что выравнивание == размер типа): len находится по адресу 0, поэтому data находится по адресу 2 и 2 % 4 != 0. Но приведение говорит компилятору: «Эти данные правильно выровнены» («... потому что в противном случае это UB, и мы никогда не столкнемся с UB»). Таким образом, во время оптимизации компилятор будет использовать инструкции SIMD / SSE для более быстрого вычисления суммы, и они дают сбой при получении невыровненных данных.
Примечание: есть невыровненные инструкции SSE, но они медленнее, и, поскольку компилятор предполагает выравнивание, которое вы обещали им здесь не используются.

Вы можете увидеть это в примере из @Antti Haapala, который я сократил и наложил на Godbolt, чтобы вы могли поиграть: https://godbolt.org/z/KOfi6V. Смотрите «программа вернула: 255» или «разбилась».

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

char* raw = receiveData();
int32_t foo = readInt(raw); raw+=4;
bool foo = readBool(raw); raw+=1;
int16_t foo = readShort(raw); raw+=2;
...

read* заботится о порядке байтов и часто реализуется следующим образом:

int32_t readInt(char* ptr){
  int32_t result = *((int32_t*) ptr);
  #if BIG_ENDIAN
  result = byteswap(result);
  #endif
}

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

Эта проблема настолько распространена, что даже Boost страдает от нее во многих версиях. Существует Boost.Endian, который предоставляет простые типы байтов. Код на C от Godbolt можно легко записать как это:

#include <cstdint>
#include <boost/endian/arithmetic.hpp>


__attribute__ ((noinline)) size_t f(boost::endian::little_uint16_t *keyc, size_t len)
{
    size_t hash = 0;
    for (size_t i = 0; i < len; ++i)
        hash += keyc[i];
    return hash;
}

struct mystruct {
    uint8_t padding;
    boost::endian::little_uint16_t contents[100];
};

int main(int argc, char** argv)
{
    mystruct s;
    size_t len = argc*25;

    for (size_t i = 0; i < len; i++)
       s.contents[i] = i * argc;

    return f(s.contents, len) != 300;
}

Тип little_uint16_t - это, по сути, всего лишь несколько символов с неявным преобразованием из / в uint16_t с byteswap, если текущее соответствие машины BIG_ENDIAN. Под капотом код, используемый Boost: endian, был похож на этот:

class little_uint16_t{
  char buffer[2];
  uint16_t value(){
    #if IS_x86
      uint16_t value = *reinterpret_cast<uint16_t*>(buffer);
    #else
    ...
    #endif
    #if BIG_ENDIAN
    swapbytes(value);
    #endif
    return value;
};

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

Однако «возможный» не означает действительный. Если компилятор заменил "стандартную" загрузку инструкцией SSE, тогда это не сработает, как можно увидеть на godbolt. Это долгое время оставалось незамеченным, потому что эти инструкции SSE просто используются при обработке больших блоков данных с помощью одной и той же операции, например добавление массива значений, что я и сделал для этого примера. Это было исправлено в , который можно перевести в 1.storeferrer с помощью Boost 1.64 «стандартная» инструкция загрузки в ASM, которая поддерживает выровненные и невыровненные данные на x86, поэтому нет замедления по сравнению с версией с приведением. Но его нельзя преобразовать в выровненные инструкции SSE без дополнительных проверок.

Вывод: не используйте быстрые клавиши с приведением типов. С подозрением относитесь к каждому приведению типов, особенно при приведении к меньшему типу, и убедитесь, что выравнивание не может быть неправильным, или используйте безопасный memcpy.

Если код не делает что-то, чтобы гарантировать, что массив символьного типа выровнен, он не должен особенно ожидать, что это будет.

Если о выравнивании позаботились, код принимает его адрес один раз, преобразует его в указатель другого типа и никогда не обращается к хранилищу никакими средствами, не производными от последнего указателя, тогда реализация, предназначенная для низкоуровневого программирования, не должна иметь особого сложность обращения с хранилищем как с абстрактным буфером. Поскольку такое лечение не будет трудным и будет необходимо для некоторых видов низкоуровневого программирования (например, реализация пулов памяти в контекстах, где malloc () может быть недоступен), реализация, которая не поддерживает такие конструкции, не должна претендовать на то, чтобы быть подходящей. для низкоуровневого программирования.

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

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