Непоследовательные строгие правила псевдонимов

У меня все еще есть проблемы с псевдонимами в моем коде (из-за initb) или это безопасно?

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

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

Вместо этого используйте memcpy:

void inita(ctx_t *ctx, uint8_t *aptr)
{
    memcpy(ctx->a, aptr, sizeof uint64_t);
}

В языках, изобретенных Деннисом Ритчи, названных C и описанных в обоих изданиях Язык программирования C (но расширенных для включения 64-битных типов), единственная проблема с приведенным выше кодом заключается в том, что нет никакой гарантии. что автоматические объекты char[] будут выровнены способом, подходящим для доступа через 64-битный указатель. Это не будет проблемой на платформах x86 или x64, но будет проблемой на платформах, основанных на других архитектурах, таких как ARM Cortex-M0.

Диалекты, обрабатываемые такими реализациями, как MSVC или icc, которые поддерживают дух C, описанный Комитетом по стандартам, включая принцип «Не мешайте программисту делать то, что нужно», и прилагают усилия для поддержки низкоуровневого программирования. , будет распознавать, что конструкция формы *(T*)pointerOfTypeU может обращаться к объекту типа U. Хотя стандарт не требует такой поддержки, это, вероятно, потому, что авторы ожидали, что реализации предпримут хотя бы некоторые усилия для распознавания ситуаций, когда указатель один тип был сформирован из lvalue другого типа, и думал, что такое распознавание можно оставить как проблему качества реализации. Обратите внимание, что в Стандарте нет ничего, что требовало бы от компилятора:

struct foo {int x[10]; };

void test(struct foo *p, int i)
{
  struct foo temp;
  temp = *p;
  temp.x[i] = 1;
  *p = temp;
}

распознать, что на объект типа struct foo могут повлиять действия по формированию int* с адресом foo.x+i, разыменованию его и последующей записи в результирующее lvalue типа int. Вместо этого авторы Стандарта полагаются на качественные реализации, чтобы попытаться распознать очевидные случаи, когда указатель или lvalue одного типа выводятся из указателя или lvalue другого.

Компилятор icc, учитывая:

int test1(int *p1, float *q1)
{
    *p1 = 1;
    *q1 = 2.0f;
    return *p1;
}
int test2(int *p2, int *q2)
{
    *p2 = 1;
    *(float*)q2 = 2.0f;
    return *p2;
}
int test3(int *p3, float volatile *q3)
{
    *p3 = 1;
    *q3 = 2.0f;
    return *p3;
}

будет предполагать, что, поскольку p1 и p2 являются разными типами, и не имеют различимой взаимосвязи, они не будут псевдонимами, но распознают, что, поскольку p2 и q2 имеют один и тот же тип, они могут идентифицировать один и тот же объект. Кроме того, он распознает, что lvalue *(float*)q2 совершенно очевидно основан на q2. Следовательно, он распознает, что доступ к *(float*)q2 может быть доступом к *p2. Кроме того, icc будет рассматривать volatile как индикацию «не предполагайте, что вы понимаете все, что здесь происходит», и, таким образом, допускает возможность того, что доступ через q3 может повлиять на другие объекты странным образом.

Некоторые компиляторы, такие как clang и gcc, если они не вынуждены через -O0 или -fno-strict-aliasing вести себя так, как это подходит для низкоуровневого программирования, интерпретируют стандарт как предлог для игнорирования очевидных взаимосвязей между lvalue разных типов, за исключением случаев, когда это может нарушить языковые конструкции. так плохо, что они практически бесполезны. Хотя они понимают, что доступ к someUnion.array[i] является доступом к someUnion, они точно так же распознают *(someUnion.array+i), даже несмотря на то, что определение someUnion.array[i] — это *(someUnion.array+i). Учитывая, что стандарт рассматривает поддержку почти всего, что связано с хранилищем смешанного типа, как проблему «качества реализации», все, что можно сказать, это то, что компиляторы, подходящие для разных целей, поддерживают разные комбинации конструкций.