¿Por qué los punteros de función y los punteros de datos son incompatibles en C / C ++?

He leído que convertir un puntero de función en un puntero de datos y viceversa funciona en la mayoría de las plataformas, pero no se garantiza que funcione. ¿Por qué es este el caso? ¿No deberían ser ambas direcciones simplemente en la memoria principal y, por lo tanto, ser compatibles?

Una arquitectura no tiene que almacenar código y datos en la misma memoria. Con una arquitectura de Harvard, el código y los datos se almacenan en una memoria completamente diferente. La mayoría de las arquitecturas son arquitecturas de Von Neumann con código y datos en la misma memoria, pero C no se limita solo a ciertos tipos de arquitecturas si es posible.

Algunas computadoras tienen (tenían) espacios de direcciones separados para código y datos. En tal hardware simplemente no funciona.

El lenguaje está diseñado no solo para las aplicaciones de escritorio actuales, sino para permitir que se implemente en un gran conjunto de hardware.

Parece que el comité del lenguaje C nunca tuvo la intención void*de ser un puntero para funcionar, solo querían un puntero genérico para los objetos.

La justificación del C99 dice:

6.3.2.3 Los punteros
C ahora se han implementado en una amplia gama de arquitecturas. Si bien algunas de estas arquitecturas presentan punteros uniformes del tamaño de algún tipo de entero, el código máximamente portátil no puede asumir la correspondencia necesaria entre los diferentes tipos de puntero y los tipos de entero. En algunas implementaciones, los punteros pueden incluso ser más anchos que cualquier tipo de entero.

El uso de void*("puntero a void") como un tipo de puntero de objeto genérico es una invención del Comité C89. La adopción de este tipo fue estimulada por el deseo de especificar argumentos de prototipo de función que conviertan silenciosamente punteros arbitrarios (como en fread) o se quejen si el tipo de argumento no coincide exactamente (como en strcmp). No se dice nada sobre punteros a funciones, que pueden ser inconmensurables con punteros de objetos y / o enteros.

Nota No se dice nada sobre los punteros a las funciones en el último párrafo. Pueden ser diferentes de otros indicadores, y el comité lo sabe.

Para aquellos que recuerdan MS-DOS, Windows 3.1 y versiones anteriores, la respuesta es bastante fácil. Todo esto solía admitir varios modelos de memoria diferentes, con diferentes combinaciones de características para punteros de código y datos.

Entonces, por ejemplo, para el modelo compacto (código pequeño, datos grandes):

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

y viceversa en el modelo Medio (código grande, datos pequeños):

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

En este caso, no tenía un almacenamiento separado para el código y la fecha, pero aún no podía convertir entre los dos punteros (salvo el uso de modificadores no estándar __near y __far).

Además, no hay garantía de que, incluso si los punteros son del mismo tamaño, apunten a lo mismo: en el modelo de memoria pequeña de DOS, tanto el código como los datos se usan cerca de los punteros, pero apuntan a diferentes segmentos. Por lo tanto, convertir un puntero de función en un puntero de datos no le daría un puntero que tuviera relación alguna con la función y, por lo tanto, no era útil para dicha conversión.

Se supone que los punteros a anular pueden acomodar un puntero a cualquier tipo de datos, pero no necesariamente un puntero a una función. Algunos sistemas tienen requisitos diferentes para punteros a funciones que punteros a datos (por ejemplo, hay DSP con diferente direccionamiento para datos frente a código, el modelo medio en MS-DOS utiliza punteros de 32 bits para código pero solo punteros de 16 bits para datos) .

Además de lo que ya se dijo aquí, es interesante mirar POSIX dlsym():

El estándar ISO C no requiere que los punteros a las funciones se puedan enviar de un lado a otro a los punteros a los datos. De hecho, el estándar ISO C no requiere que un objeto de tipo void * pueda contener un puntero a una función. Sin embargo, las implementaciones que admiten la extensión XSI requieren que un objeto de tipo void * pueda contener un puntero a una función. Sin embargo, el resultado de convertir un puntero a una función en un puntero a otro tipo de datos (excepto void *) aún no está definido. Tenga en cuenta que los compiladores que cumplen con el estándar ISO C deben generar una advertencia si se intenta una conversión de un puntero nulo * a un puntero de función como en:

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

Debido al problema señalado aquí, una versión futura puede agregar una nueva función para devolver punteros de función, o la interfaz actual puede quedar en desuso en favor de dos nuevas funciones: una que devuelve punteros de datos y la otra que devuelve punteros de función.

C ++ 11 tiene una solución al desajuste de larga data entre C / C ++ y POSIX con respecto a dlsym(). Se puede usar reinterpret_castpara convertir un puntero de función a / desde un puntero de datos siempre que la implementación admita esta característica.

De la norma, 5.2.10 párr. 8, "la conversión de un puntero de función a un tipo de puntero de objeto o viceversa es compatible condicionalmente". 1.3.5 define "condicionalmente soportado" como una "construcción de programa que no es necesaria una implementación para soportar".

Dependiendo de la arquitectura de destino, el código y los datos pueden almacenarse en áreas de memoria fundamentalmente incompatibles y físicamente distintas.

indefinido no necesariamente significa no permitido, puede significar que el implementador del compilador tiene más libertad para hacerlo como ellos quieran.

Por ejemplo, puede que no sea posible en algunas arquitecturas: indefinido les permite tener una biblioteca 'C' conforme, incluso si no puede hacerlo.

Otra solución:

Suponiendo que POSIX garantiza que los punteros de función y datos tengan el mismo tamaño y representación (no puedo encontrar el texto para esto, pero el ejemplo OP citado sugiere que al menos pretendieron hacer este requisito), lo siguiente debería funcionar:

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

Esto evita violar las reglas de alias al pasar por la char []representación, que permite alias de todos los tipos.

Otro enfoque más:

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

Pero recomendaría el memcpyenfoque si desea una C 100% correcta.

Pueden ser diferentes tipos con diferentes requisitos de espacio. Asignar a uno puede cortar irreversiblemente el valor del puntero para que la asignación de resultados resulte en algo diferente.

Creo que pueden ser de diferentes tipos porque el estándar no quiere limitar las posibles implementaciones que ahorran espacio cuando no es necesario o cuando el tamaño podría hacer que la CPU tenga que hacer más basura para usarlo, etc.

La única solución verdaderamente portátil es no usar dlsympara funciones, y en su lugar usar dlsympara obtener un puntero a datos que contengan punteros de función. Por ejemplo, en tu biblioteca:

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

y luego en su aplicación:

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

Por cierto, esta es una buena práctica de diseño de todos modos, y hace que sea fácil admitir la carga dinámica a través dlopeny la vinculación estática de todos los módulos en sistemas que no admiten la vinculación dinámica, o donde el usuario / integrador del sistema no quiere utilizar la vinculación dinámica.

Un ejemplo moderno de dónde los punteros de función pueden diferir en tamaño de los punteros de datos: punteros de función miembro de clase C ++

Citado directamente de 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(); };

Ahora hay dos posibles thispunteros.

Un puntero a una función miembro de Base1puede usarse como un puntero a una función miembro de Derived, ya que ambos usan el mismo this puntero. Pero un puntero a una función miembro de Base2no se puede usar tal cual como puntero a una función miembro de Derived, ya que el this puntero debe ajustarse.

Hay muchas formas de resolver esto. Así es como el compilador de Visual Studio decide manejarlo:

Un puntero a una función miembro de una clase de herencia múltiple es realmente una estructura.

[Address of function]
[Adjustor]

El tamaño de una función de puntero a miembro de una clase que usa herencia múltiple es el tamaño de un puntero más el tamaño de a size_t.

tl; dr: cuando se usa la herencia múltiple, un puntero a una función miembro puede (dependiendo del compilador, versión, arquitectura, etc.) realmente almacenarse como

struct { 
    void * func;
    size_t offset;
}

que obviamente es más grande que a void *.

En la mayoría de las arquitecturas, los punteros a todos los tipos de datos normales tienen la misma representación, por lo que la conversión entre tipos de punteros de datos no es una opción.

Sin embargo, es concebible que los punteros de función requieran una representación diferente, tal vez sean más grandes que otros punteros. Si void * pudiera contener punteros de función, esto significaría que la representación de void * tendría que ser de mayor tamaño. Y todos los moldes de punteros de datos a / desde void * tendrían que realizar esta copia adicional.

Como alguien mencionó, si necesita esto, puede lograrlo utilizando una unión. Pero la mayoría de los usos de void * son solo para datos, por lo que sería oneroso aumentar todo el uso de memoria en caso de que sea necesario almacenar un puntero de función.

Sé que esto no ha sido comentada desde 2012, pero pensé que sería útil añadir que yo hago conocer una arquitectura que tiene muy punteros incompatibles para datos y funciones desde una llamada en la que la arquitectura cheques privilegio y lleva la información adicional. Ninguna cantidad de casting ayudará. Es el molino .