Каково обоснование строгого правила псевдонимов?

Это позволяет компилятору оптимизировать перезагрузку переменных, не требуя, чтобы вы ограничивали свои указатели.

Пример:

int f(long *L, short *S)
{
    *L=42;
    *S=43;
    return *L;
}

int g(long *restrict L, short *restrict S)
{
    *L=42;
    *S=43;
    return *L;
}

Скомпилировано с gcc -O3 -fno-strict-aliasing на x86_64:

f:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movq    (%rdi), %rax ; <<*L reloaded here cuz *S =43 might have changed it
        ret
g:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movl    $42, %eax     ; <<42 constant-propagated from *L=42 because *S=43 cannot have changed it  (because of `restrict`)
        ret

Скомпилировано с gcc -O3 (подразумевается -fstrict-alising) на x86_64:

f:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movl    $42, %eax   ; <<same as w/ restrict
        ret
g:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movl    $42, %eax
        ret

https://gcc.godbolt.org/z/rQDNGt

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

Языки программирования предназначены для поддержки того, что члены комитета по стандартизации считают разумной и здравой практикой. Использование разных указателей очень существенно разных типов, создающих псевдонимы одного и того же объекта, считалось неразумным и что-то, что компиляторы не должны были делать изо всех сил, чтобы сделать это возможным.

Такой код:

float f(int *pi, float *pf) {
  *pi = 1;
  return *pf;
}

при использовании с pi и pf, имеющими один и тот же адрес, где *pf предназначен для переинтерпретации битов недавно написанного *pi, считается неразумным, поэтому уважаемые члены комитета (а до них разработчики C язык) не считал уместным требовать от компилятора избегать преобразования программы здравого смысла в несколько более сложном примере:

float f(int *pi, double *pf) {
  (*pi)++;
  (*pf) *= 2.;
  (*pi)++;
}

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

float f(int *pi, double *pf) {
  (*pf) *= 2.;
  (*pi) += 2;
}

В сноске к N1570 p6.5p7 четко указана цель правила: сказать, когда что-то может алиаситься. Что касается того, почему правило написано таким образом, чтобы запрещать конструкции, подобные вашей, которые не включают в себя псевдонимы, как написано (поскольку все обращения с использованием uint32_t* выполняются в контекстах, где он явно получен из uint64_t, это, скорее всего, потому, что авторы Стандарта признали, что любой, кто добросовестно пытается создать качественную реализацию, подходящую для низкоуровневого программирования, будет поддерживать конструкции, подобные вашей (как «популярное расширение»), независимо от того, предписывается ли это Стандартом. тот же принцип проявляется более явно в отношении таких конструкций, как:

unsigned mulMod65536(unsigned short x, unsigned short y)
{ return (x*y) & 65535u; }

Согласно Обоснованию, стандартные реализации будут обрабатывать операции над короткими значениями без знака способом, эквивалентным арифметике без знака, даже если результат находится между INT_MAX+1u и UINT_MAX, кроме случаев, когда применяются определенные условия. Нет необходимости в специальном правиле, заставляющем компилятор обрабатывать выражения, включающие короткие беззнаковые типы, как беззнаковые, когда результаты принудительно приводятся к unsigned, потому что, согласно авторам Стандарта, обычные реализации делают это даже без такого правило.

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