Por que ponteiros de função e ponteiros de dados são incompatíveis em C / C ++?

Eu li que converter um ponteiro de função em um ponteiro de dados e vice-versa funciona na maioria das plataformas, mas não é garantido que funcione. Por que esse é o caso? Os dois não deveriam ser simplesmente endereços na memória principal e, portanto, ser compatíveis?

Uma arquitetura não precisa armazenar código e dados na mesma memória. Com uma arquitetura de Harvard, o código e os dados são armazenados em uma memória completamente diferente. A maioria das arquiteturas são arquiteturas de Von Neumann com código e dados na mesma memória, mas C não se limita a apenas certos tipos de arquiteturas, se possível.

Alguns computadores possuem (tinham) espaços de endereço separados para código e dados. Em tal hardware, simplesmente não funciona.

O idioma foi projetado não apenas para aplicativos de desktop atuais, mas para permitir sua implementação em um grande conjunto de hardware.

Parece que o comitê de linguagem C nunca pretendeu void*ser um ponteiro para funcionar, eles apenas queriam um ponteiro genérico para objetos.

A justificativa do C99 diz:

6.3.2.3 Os ponteiros
C foram implementados em uma ampla variedade de arquiteturas. Enquanto algumas dessas arquiteturas apresentam ponteiros uniformes com o tamanho de algum tipo inteiro, o código portátil máximo não pode assumir nenhuma correspondência necessária entre os diferentes tipos de ponteiros e os tipos inteiros. Em algumas implementações, os ponteiros podem até ser mais largos do que qualquer tipo inteiro.

O uso de void*("ponteiro para void") como um tipo genérico de ponteiro de objeto é uma invenção do Comitê C89. A adoção desse tipo foi estimulada pelo desejo de especificar argumentos de protótipo de função que convertem silenciosamente ponteiros arbitrários (como em fread) ou reclamam se o tipo de argumento não corresponde exatamente (como em strcmp). Nada é dito sobre ponteiros para funções, que podem ser incomensuráveis ​​com ponteiros de objetos e / ou números inteiros.

Nota Nada é dito sobre ponteiros para funções no último parágrafo. Eles podem ser diferentes de outros indicadores, e o comitê está ciente disso.

Para aqueles que se lembram do MS-DOS, Windows 3.1 e anteriores, a resposta é bastante fácil. Tudo isso usado para suportar vários modelos de memória diferentes, com combinações variadas de características para indicadores de código e dados.

Por exemplo, para o modelo Compact (código pequeno, dados grandes):

sizeof(void *) > sizeof(void(*)())

e, inversamente, no modelo Médio (código grande, dados pequenos):

sizeof(void *) < sizeof(void(*)())

Nesse caso, você não tinha armazenamento separado para código e data, mas ainda não conseguiu converter entre os dois ponteiros (exceto por usar modificadores __near e __far não padronizados).

Além disso, não há garantia de que, mesmo que os ponteiros tenham o mesmo tamanho, eles apontem para a mesma coisa - no modelo de memória DOS pequeno, código e dados usados ​​perto de ponteiros, mas apontaram para segmentos diferentes. Portanto, converter um ponteiro de função em um ponteiro de dados não forneceria um ponteiro que tivesse qualquer relação com a função e, portanto, não havia utilidade para essa conversão.

Os ponteiros para anular devem ser capazes de acomodar um ponteiro para qualquer tipo de dados - mas não necessariamente um ponteiro para uma função. Alguns sistemas têm requisitos diferentes para ponteiros para funções e ponteiros para dados (por exemplo, existem DSPs com endereços diferentes para dados versus código, o modelo médio no MS-DOS usou ponteiros de 32 bits para código, mas apenas ponteiros de 16 bits para dados) .

Além do que já foi dito aqui, é interessante observar o POSIX dlsym():

O padrão ISO C não exige que ponteiros para funções possam ser convertidos para ponteiros para dados. De fato, o padrão ISO C não exige que um objeto do tipo void * possa conter um ponteiro para uma função. As implementações que suportam a extensão XSI, no entanto, exigem que um objeto do tipo void * possa conter um ponteiro para uma função. O resultado da conversão de um ponteiro para uma função em um ponteiro para outro tipo de dados (exceto nulo *) ainda é indefinido, no entanto. Observe que os compiladores em conformidade com o padrão ISO C são necessários para gerar um aviso se uma conversão de um ponteiro void * em um ponteiro de função for tentada como em:

 fptr = (int (*)(int))dlsym(handle, "my_function");

Devido ao problema observado aqui, uma versão futura pode adicionar uma nova função para retornar ponteiros de função ou a interface atual pode ser preterida em favor de duas novas funções: uma que retorna ponteiros de dados e a outra que retorna ponteiros de função.

O C ++ 11 possui uma solução para a incompatibilidade de longa data entre C / C ++ e POSIX em relação a dlsym(). Pode-se usarreinterpret_cast para converter um ponteiro de função para / de um ponteiro de dados, desde que a implementação suporte esse recurso.

A partir do padrão, 5.2.10 para. 8, "a conversão de um ponteiro de função em um tipo de ponteiro de objeto ou vice-versa é suportada condicionalmente". 1.3.5 define "com suporte condicional" como uma "construção de programa que uma implementação não precisa suportar".

Dependendo da arquitetura de destino, o código e os dados podem ser armazenados em áreas da memória fundamentalmente incompatíveis e fisicamente distintas.

undefined não significa necessariamente não permitido, pode significar que o implementador do compilador tem mais liberdade para fazê-lo como quiser.

Por exemplo, pode não ser possível em algumas arquiteturas - indefinido permite que eles ainda tenham uma biblioteca 'C' em conformidade, mesmo que você não possa fazer isso.

Outra solução:

Supondo que o POSIX garanta que os ponteiros de função e dados tenham o mesmo tamanho e representação (não consigo encontrar o texto para isso, mas o exemplo do OP citado sugere que eles pelo menos pretendiam fazer esse requisito), o seguinte deve funcionar:

double (*cosine)(double);
void *tmp;
handle = dlopen("libm.so", RTLD_LAZY);
tmp = dlsym(handle, "cos");
memcpy(&cosine, &tmp, sizeof cosine);

Isso evita violar as regras de aliasing, passando pelo char [] representação, que é permitida para alias todos os tipos.

Ainda outra abordagem:

union {
    double (*fptr)(double);
    void *dptr;
} u;
u.dptr = dlsym(handle, "cos");
cosine = u.fptr;

Mas eu recomendaria a memcpyabordagem se você quiser absolutamente 100% de C. correto

Eles podem ser diferentes tipos com diferentes requisitos de espaço. Atribuir a um pode fatiar irreversivelmente o valor do ponteiro, de modo que atribuir de volta resulta em algo diferente.

Eu acredito que eles podem ser de tipos diferentes porque o padrão não deseja limitar possíveis implementações que economizam espaço quando não é necessário ou quando o tamanho pode fazer com que a CPU precise fazer uma porcaria extra para usá-lo, etc.

A única solução verdadeiramente portátil é não usar dlsympara funções e, em vez disso, usar dlsympara obter um ponteiro para dados que contém ponteiros de função. Por exemplo, na sua biblioteca:

struct module foo_module = {
    .create = create_func,
    .destroy = destroy_func,
    .write = write_func,
    /* ... */
};

e depois no seu aplicativo:

struct module *foo = dlsym(handle, "foo_module");
foo->create(/*...*/);
/* ... */

De qualquer forma, essa é uma boa prática de design e facilita o suporte ao carregamento dinâmico por meio de dlopenvinculação estática e todos os módulos em sistemas que não suportam a vinculação dinâmica ou onde o usuário / integrador de sistemas não deseja usar a vinculação dinâmica.

Um exemplo moderno de onde os ponteiros de função podem diferir em tamanho dos ponteiros de dados: ponteiros de função de membro da classe C ++

Citado diretamente em https://blogs.msdn.microsoft.com/oldnewthing/20040209-00/?p=40713/

class Base1 { int b1; void Base1Method(); };
class Base2 { int b2; void Base2Method(); };
class Derived : public Base1, Base2 { int d; void DerivedMethod(); };

Agora existem dois possíveis this indicadores .

Um ponteiro para uma função de membro de Base1pode ser usado como um ponteiro para uma função de membro de Derived, uma vez que ambos usam o mesmo this ponteiro. Mas um ponteiro para uma função membro de Base2não pode ser usado como está como um ponteiro para uma função membro de Derived, uma vez que othis ponteiro precisa ser ajustado.

Existem muitas maneiras de resolver isso. Veja como o compilador do Visual Studio decide lidar com isso:

Um ponteiro para uma função de membro de uma classe herdada de multiplicação é realmente uma estrutura.

[Address of function]
[Adjustor]

O tamanho de uma função de ponteiro para membro de uma classe que usa herança múltipla é o tamanho de um ponteiro mais o tamanho de a size_t.

tl; dr: Ao usar herança múltipla, um ponteiro para uma função membro pode (dependendo do compilador, versão, arquitetura, etc.) ser realmente armazenado como

struct { 
    void * func;
    size_t offset;
}

que é obviamente maior que a void *.

Na maioria das arquiteturas, os ponteiros para todos os tipos de dados normais têm a mesma representação; portanto, a conversão entre tipos de ponteiros de dados não é uma opção.

No entanto, é concebível que os ponteiros de função possam exigir uma representação diferente, talvez eles sejam maiores que outros ponteiros. Se o void * pudesse conter ponteiros de função, isso significaria que a representação do void * teria que ser do tamanho maior. E todas as transmissões de ponteiros de dados para / do void * teriam que executar essa cópia extra.

Como alguém mencionou, se você precisar disso, poderá obtê-lo usando um sindicato. Mas a maioria dos usos do void * é apenas para dados, portanto, seria oneroso aumentar todo o uso de memória apenas no caso de um ponteiro de função precisar ser armazenado.

Eu sei que isso não foi comentada desde 2012, mas eu pensei que seria útil acrescentar que eu faço saber uma arquitetura que tem muito ponteiros incompatíveis para dados e funções desde uma chamada em que o privilégio arquitetura cheques e carrega a informação extra. Nenhuma quantidade de elenco ajudará. É o moinho .