типа агностика тетсра в C99

Question

Связанных, но несколько отличается от, Do any compilers transfer effective type through memcpy/memmove

В C89, memcpy и memmove должны вести себя так, как будто источник и назначение доступны с использованием типов символов, копированием всех бит источник для адресата без учета типа копируемых данных.

C99 изменяет семантику так, что если объект с эффективным типом копируется в хранилище, у которого нет объявленного типа [обычно это память, полученная от malloc или другой такой функции], он создает объект в целевом хранилище, к которому можно получить доступ используя тип источника.

В следующем коде, например, было бы полностью определено поведение в C89 на всех платформах, где «unsigned int» и «unsigned long» имеют одно и то же 32-битное представление, но имели бы Undefined Behavior под C99.

#include <stdio.h> 
#include <string.h> 
void increment_32_bit_uint(void *p) 
{ 
    uint32_t temp; 
    memcpy(&temp, p, sizeof temp); 
    temp++; 
    memcpy(p, &temp, sizeof temp); 
} 
int main(void) 
{ 
    unsigned *ip = malloc(sizeof (unsigned)); 
    unsigned long *lp = malloc(sizeof (unsigned long)); 
    *ip = 3; *lp = 6; 
    increment_32_bit_uint(ip); 
    increment_32_bit_uint(lp);  
    printf("%u %lu", *ip, *lp); 
    return 0; 
} 

Согласно правилам C99, передавая выделенную память для функции «increment_32_bit_uint» сделает это установить эффективный тип для uint32_t, которая не может быть такого же типа, как и «без знака» и «без знака долго», даже если все три типы имеют одинаковое представление. Следовательно, компилятор может делать все, что ему нравится, с кодом, который читает это хранилище как тип, отличный от uint32_t, даже если этот тип имеет такое же представление.

Есть ли способ на C99 или C11 выполнить копию таким образом, чтобы компилятор мог генерировать эффективный код, но заставил компилятор обрабатывать адресат так, как если бы он содержал шаблон бит без эффективный тип [который можно было бы получить с помощью любого типа]?

Answer 1

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

uint32_t increment_32_bit_uint (const void* p) 
{ 
    u32_t result; 
    memcpy(&result, p, sizeof(result)); 
    result++; 
    return result; 
} 

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

x = increment_32_bit_uint(&x); 

---

Вообще, я не понимаю, как любые строгие сглаживания оптимизаций когда-либо будет полезно в реальных приложений, если они не рассматривают типы stdint.h как совместимые типы для их примитивных эквивалентов типа данных. В частности, он должен обрабатывать uint8_t в качестве символьного типа, или весь профессиональный низкоуровневый код C сломается.

То же самое для вашего случая здесь. Если компилятор знает, что unsigned int 32 бит, почему он решил вызвать проблемы с псевдонимом для пользователей uint32_t и наоборот? Вот как вы превращаете компилятор бесполезно.