Início / coding / Perguntas / 79491065
Accepted
CPlus
Asked: 2025-03-07 09:44:45 +0800 CST

Um tipo de ponto flutuante real pode ser um alias para um tipo de ponto flutuante complexo em C?

  • 772

De acordo com o Padrão C :

Cada tipo complexo tem os mesmos requisitos de representação e alinhamento de um tipo de matriz contendo exatamente dois elementos do tipo real correspondente; o primeiro elemento é igual à parte real e o segundo elemento à parte imaginária do número complexo.

Dessa forma, é possível lançar com segurança a _Complex float *em a float *e então acessar os componentes reais/imaginários usando o float *? Ou isso ainda violaria tecnicamente o aliasing estrito e, portanto, invocaria um comportamento indefinido?

_Complex float c;

((float *)&c)[0] = 1;
((float *)&c)[1] = 2;

c; // 1 + 2i
c

1 respostas

  1. Best Answer

    C 2018 6.2.5 13 e C 2024 6.2.5 dizem:

    Cada tipo complexo tem os mesmos requisitos de representação e alinhamento de um tipo de matriz contendo exatamente dois elementos do tipo real correspondente; o primeiro elemento é igual à parte real e o segundo elemento à parte imaginária do número complexo.

    Isso garante que você possa usar memcpypara copiar os bytes que representam uma matriz de 2 N float objetos para os bytes de uma matriz de N complex float objetos, ou vice-versa, e obter os resultados naturalmente esperados: como eles têm a mesma representação na memória, e o padrão C suporta a leitura e atualização dos bytes que representam objetos por meio de memcpyoutros mecanismos de cópia de caracteres, isso reproduzirá os valores.

    É menos claro que isso significa que você pode criar um alias para a mesma memória usando os diferentes tipos, que é o que você faz convertendo um ponteiro e desreferenciando no novo tipo. Formalmente, isso não está em conformidade com as regras de aliasing em C 2018 6.5 7 ou C 2024 6.5. No entanto, ao discutir outro caso em que o padrão impõe requisitos de que as representações sejam idênticas, C 2018 6.2.5 9 e C 2024 6.2.5 dizem na nota não normativa 41 (C 2018) e 34 (C 2024):

    Os mesmos requisitos de representação e alinhamento pretendem implicar intercambiabilidade como argumentos para funções, valores de retorno de funções e membros de uniões.

    Esta frase sobre a “mesma representação” é usada várias vezes no padrão com a intenção, de acordo com as notas, de tornar vários pares de tipos intercambiáveis ​​de alguma forma vaga que o padrão não define. Esta informação conflitante entre aliasing e intercambialidade é um defeito de longa data no padrão C, e pode-se interpretar a intercambialidade como anulando ou vindo antes das regras de aliasing. Ou seja, os autores do padrão queriam que pudéssemos aliasar coisas que eram necessárias para ter os mesmos requisitos de representação e alinhamento, mas o comitê não conseguiu escrever regras formais para isso. No entanto, essa interpretação não pode ser considerada uma declaração formal do padrão C e, portanto, não é estritamente garantido que aliasing um objeto complexo como uma matriz de dois elementos reais seja definido.

    Suplemento

    Na minha experiência com vários compiladores, eles suportarão esse aliasing em particular. Otimizações serão feitas assumindo, por exemplo, que intos floattipos e não aliasam a mesma memória, mas não que a “remodelagem de array” (reinterpretação de um array multidimensional como um array de outras dimensões) não ocorrerá, incluindo esse tratamento de complex doubleobjetos e arrays de double. Se você estiver escrevendo software acadêmico para estudar alguns modelos científicos e o risco de estar errado sobre essa interpretação do padrão C é que respostas erradas podem ser produzidas, esse pode ser um risco que você está disposto a correr. Se você estiver escrevendo software crítico de segurança, não deve confiar nessa interpretação sem asserções dos desenvolvedores do compilador.

    • 2

relate perguntas