Início / coding / Perguntas / 77852527
Accepted
schuelermine
Asked: 2024-01-21 04:01:32 +0800 CST

Posso mover-me entre sequências contíguas de campos do mesmo tipo em uma estrutura usando aritmética de ponteiro sem alinhamento?

  • 772

Estou ciente de que existem outras questões semelhantes. Eu li isso e não acho que essa pergunta tenha sido respondida.

Posso mover-me entre uma sequência consecutiva (contígua na sequência de declaração) de campos do mesmo tipo de uma estrutura usando aritmética de ponteiro sem consultar _Alignof?

Posso mover-me entre os elementos da matriz sem consultar _Alignofporque o preenchimento final está incluído.

No entanto, é possível que campos consecutivos do mesmo tipo em uma estrutura não estejam alinhados da mesma forma que em uma matriz?

Em outras palavras, é possível que esse código tenha um comportamento indefinido?

struct MyStruct {
    long int field_1;
    int field_2;
    int field_3;
};

int main(void) {
    struct MyStruct my_struct;
    int *field_2_ptr = &my_struct.field_2;
    int field_3_value = *(field_2_ptr + 1);
}

Eu sei que isso é uma má prática. Estou ciente . _ ->Eu sei que o preenchimento pode interferir em geral. Quero saber se o preenchimento pode interferir nesta circunstância específica.

Esta questão é sobre C. Não me importo com C++.

Até agora eu compilei isso com o GCC e experimentei o Valgrind para ver se algo estava errado, e compilei com clang e UBSan. Parece estar bem neste sistema (x86-64 Linux).

c

3 respostas

  1. Best Answer

    A rigor, este é um comportamento indefinido.

    A aritmética de ponteiro é permitida em objetos de matriz (e objetos únicos são tratados como uma matriz de 1 elemento para essa finalidade), desde que o ponteiro original e o ponteiro resultante apontem para o mesmo objeto de matriz (ou um elemento após o final). Além disso, um ponteiro para um após o fim não pode ser desreferenciado, caso contrário, acionará um comportamento indefinido.

    Isso está explicado na seção 6.5.6p8 do padrão C em relação aos operadores aditivos:

    Quando uma expressão do tipo inteiro é adicionada ou subtraída de um ponteiro, o resultado tem o tipo do operando do ponteiro. Se o operando do ponteiro apontar para um elemento de um objeto de matriz, e a matriz for grande o suficiente, o resultado aponta para um deslocamento do elemento do elemento original, de modo que a diferença dos subscritos dos elementos da matriz resultante e original seja igual à expressão inteira. Em outras palavras, se a expressão P aponta para o i-ésimo elemento de um objeto de matriz, as expressões (P)+N (equivalentemente, N+(P)) e (P)-N (onde N tem o valor n) apontam para, respectivamente, os i+n-ésimo e i-n-ésimo elementos do objeto array, desde que existam. Além disso, se a expressão P aponta para o último elemento de um objeto array, a expressão (P)+1 aponta um após o último elemento do objeto array, e se a expressão Q aponta para o último elemento de um objeto de matriz, a expressão (Q)-1 aponta para o último elemento do objeto de matriz. Se tanto o operando do ponteiro quanto o resultado apontarem para elementos do mesmo objeto array, ou um após o último elemento do objeto array, a avaliação não produzirá um overflow; caso contrário, o comportamento será indefinido.Se o resultado apontar para o último elemento do objeto array, ele não deve ser usado como operando de um * operador unário que é avaliado.

    A seção em negrito é exatamente o que está acontecendo aqui:

    int field_3_value = *(field_2_ptr + 1);

    Como isso desreferencia um ponteiro para outro elemento de (essencialmente) uma matriz de 1 elemento, isso desencadeia um comportamento indefinido. Isso &my_struct.field_2 + 1 == &my_struct.field_3seria avaliado como verdadeiro, não importa.

    Pela mesma razão, este também é um comportamento indefinido:

    int x[2][2] = {{1,2},{3,4}};
int y = x[0][2];

    Embora o procedimento acima provavelmente funcione, não há garantia disso. Os compiladores modernos otimizam agressivamente e podem e assumem que não existe comportamento indefinido e exploram essa suposição.

    Já vi casos em que, dados ponteiros ae bque apontam para a memória adjacente, (uintptr_t)(a+1) == (uintptr_t)bsão verdadeiros, mas a+1 == bsão falsos.

    • 4

  2. Como @dbush escreveu, é um UB.

    Eu usaria um array para agrupar membros do mesmo tipo:

    struct MyStruct {
    long int field_1;
    int fields[2];
};

    e seu código não invocará um UB

    int main(void) {
    struct MyStruct my_struct;
    int *field_2_ptr = my_struct.fields;
    int field_3_value = *(field_2_ptr + 1);

    /* or more simple */
    int field_3_value = my_struct.fields[1];

}
    • 0

  3. Esse tipo de comportamento foi definido na linguagem que o Padrão C foi designado para descrever, e o Padrão C permite que implementações, como uma forma de "extensão de linguagem conforme", suportem tais construções. Clang e gcc suportarão tais construções quando invocados com o -fno-strict-alisingsinalizador do compilador, embora não se deva esperar que eles suportem tais construções de outra forma.

    • 0

relate perguntas