Conversión de un puntero de función a otro tipo

Digamos que tengo una función que acepta un void (*)(void*)puntero de función para usar como devolución de llamada:

void do_stuff(void (*callback_fp)(void*), void* callback_arg);

Ahora, si tengo una función como esta:

void my_callback_function(struct my_struct* arg);

¿Puedo hacer esto de forma segura?

do_stuff((void (*)(void*)) &my_callback_function, NULL);

He examinado esta pregunta y he examinado algunos estándares de C que dicen que puede convertir a 'punteros de función compatibles', pero no puedo encontrar una definición de lo que significa 'puntero de función compatible'.

En lo que respecta al estándar C, si lanza un puntero de función a un puntero de función de un tipo diferente y luego lo llama, es un comportamiento indefinido . Ver Anexo J.2 (informativo):

El comportamiento no está definido en las siguientes circunstancias:

• Un puntero se usa para llamar a una función cuyo tipo no es compatible con el tipo apuntado (6.3.2.3).

La sección 6.3.2.3, párrafo 8 dice:

Un puntero a una función de un tipo puede convertirse en un puntero a una función de otro tipo y viceversa; el resultado se comparará igual al puntero original. Si se utiliza un puntero convertido para llamar a una función cuyo tipo no es compatible con el tipo apuntado, el comportamiento no está definido.

En otras palabras, puede convertir un puntero de función a un tipo de puntero de función diferente, devolverlo de nuevo y llamarlo, y todo funcionará.

La definición de compatible es algo complicada. Se puede encontrar en la sección 6.7.5.3, párrafo 15:

Para que dos tipos de funciones sean compatibles, ambos especificarán tipos de retorno compatibles ¹²⁷ .

Además, las listas de tipos de parámetros, si ambos están presentes, coincidirán en el número de parámetros y en el uso del terminador de puntos suspensivos; los parámetros correspondientes deberán tener tipos compatibles. Si un tipo tiene una lista de tipos de parámetros y el otro tipo está especificado por un declarador de función que no forma parte de una definición de función y que contiene una lista de identificadores vacía, la lista de parámetros no tendrá un terminador de puntos suspensivos y el tipo de cada parámetro deberá ser compatible con el tipo que resulta de la aplicación de las promociones de argumento por defecto. Si un tipo tiene una lista de tipos de parámetros y el otro tipo se especifica mediante una definición de función que contiene una lista de identificadores (posiblemente vacía), ambos estarán de acuerdo en el número de parámetros, y el tipo de cada parámetro prototipo será compatible con el tipo que resulte de la aplicación de las promociones de argumentos por defecto al tipo del identificador correspondiente. (En la determinación de la compatibilidad de tipos y de un tipo compuesto, cada parámetro declarado con función o tipo de matriz se considera que tiene el tipo ajustado y cada parámetro declarado con tipo calificado se considera que tiene la versión no calificada de su tipo declarado).

127) Si ambos tipos de funciones son "estilo antiguo", los tipos de parámetros no se comparan.

Las reglas para determinar si dos tipos son compatibles se describen en la sección 6.2.7, y no las citaré aquí porque son bastante extensas, pero puede leerlas en el borrador del estándar C99 (PDF) .

La regla relevante aquí está en la sección 6.7.5.1, párrafo 2:

Para que dos tipos de punteros sean compatibles, ambos deben estar calificados de manera idéntica y ambos deben ser punteros a tipos compatibles.

Por lo tanto, dado que a void* no es compatible con a struct my_struct*, un puntero de función de tipo void (*)(void*)no es compatible con un puntero de función de tipo void (*)(struct my_struct*), por lo que esta conversión de punteros de función es un comportamiento técnicamente indefinido.

Sin embargo, en la práctica, en algunos casos puede salirse con la suya sin problemas con los punteros de función de lanzamiento. En la convención de llamadas x86, los argumentos se insertan en la pila y todos los punteros tienen el mismo tamaño (4 bytes en x86 u 8 bytes en x86_64). Llamar a un puntero de función se reduce a empujar los argumentos en la pila y hacer un salto indirecto al destino del puntero de función, y obviamente no hay noción de tipos a nivel de código de máquina.

Cosas que definitivamente no puedes hacer:

• Conversión entre punteros de función de diferentes convenciones de llamada. Arruinará la pila y, en el mejor de los casos, se estrellará, en el peor, tendrá éxito en silencio con un enorme agujero de seguridad. En la programación de Windows, a menudo se pasan punteros de función. Win32 espera que todas las funciones de devolución de llamada para utilizar la stdcallconvención de llamada (que las macros CALLBACK, PASCALy WINAPItodo se expanden a). Si pasa un puntero de función que usa la convención de llamada estándar de C ( cdecl), resultará mal.
• En C ++, conversión entre punteros de función de miembro de clase y punteros de función regulares. Esto a menudo hace tropezar a los novatos de C ++. Las funciones miembro de la clase tienen un thisparámetro oculto , y si convierte una función miembro a una función normal, no hay ningún thisobjeto para usar y, nuevamente, resultará en mucha maldad.

Otra mala idea que a veces puede funcionar, pero también es un comportamiento indefinido:

• Conversión entre punteros de función y punteros regulares (por ejemplo, conversión de a void (*)(void)a a void*). Los punteros de función no tienen necesariamente el mismo tamaño que los punteros normales, ya que en algunas arquitecturas pueden contener información contextual adicional. Esto probablemente funcionará bien en x86, pero recuerde que es un comportamiento indefinido.

Pregunté sobre este mismo problema con respecto a algún código en GLib recientemente. (GLib es una biblioteca central para el proyecto GNOME y está escrita en C.) Me dijeron que todo el marco de slots'n'signals depende de ello.

A lo largo del código, existen numerosos casos de conversión del tipo (1) al (2):

1. typedef int (*CompareFunc) (const void *a, const void *b)
2. typedef int (*CompareDataFunc) (const void *b, const void *b, void *user_data)

Es común encadenar con llamadas como esta:

int stuff_equal (GStuff      *a,
                 GStuff      *b,
                 CompareFunc  compare_func)
{
    return stuff_equal_with_data(a, b, (CompareDataFunc) compare_func, NULL);
}

int stuff_equal_with_data (GStuff          *a,
                           GStuff          *b,
                           CompareDataFunc  compare_func,
                           void            *user_data)
{
    int result;
    /* do some work here */
    result = compare_func (data1, data2, user_data);
    return result;
}

Véalo usted mismo aquí en g_array_sort(): http://git.gnome.org/browse/glib/tree/glib/garray.c

Las respuestas anteriores son detalladas y probablemente correctas, si forma parte del comité de normas. Adam y Johannes merecen crédito por sus respuestas bien investigadas. Sin embargo, en la naturaleza, encontrará que este código funciona bien. ¿Polémico? Si. Considere esto: GLib compila / trabaja / prueba en una gran cantidad de plataformas (Linux / Solaris / Windows / OS X) con una amplia variedad de compiladores / enlazadores / cargadores de kernel (GCC / CLang / MSVC). Al diablo con los estándares, supongo.

Pasé algún tiempo pensando en estas respuestas. Aquí está mi conclusión:

1. Si está escribiendo una biblioteca de devolución de llamada, esto podría estar bien. Caveat emptor: utilícelo bajo su propio riesgo.
2. De lo contrario, no lo hagas.

Pensando más profundamente después de escribir esta respuesta, no me sorprendería si el código para los compiladores de C usa este mismo truco. Y dado que (¿la mayoría / todos?) Los compiladores de C modernos son bootstrap, esto implicaría que el truco es seguro.

Una pregunta más importante para investigar: ¿Puede alguien encontrar una plataforma / compilador / enlazador / cargador donde este truco funciona? no funcione? Grandes puntos de brownie para ese. Apuesto a que hay algunos procesadores / sistemas integrados a los que no les gusta. Sin embargo, para computadoras de escritorio (y probablemente móviles / tabletas), este truco probablemente aún funcione.

El punto realmente no es si puedes. La solución trivial es

void my_callback_function(struct my_struct* arg);
void my_callback_helper(void* pv)
{
    my_callback_function((struct my_struct*)pv);
}
do_stuff(&my_callback_helper);

Un buen compilador solo generará código para my_callback_helper si es realmente necesario, en cuyo caso te alegrarás de que así sea.

Tiene un tipo de función compatible si el tipo de retorno y los tipos de parámetros son compatibles, básicamente (es más complicado en realidad :)). La compatibilidad es la misma que "mismo tipo", pero más laxa para permitir tener diferentes tipos, pero aún así tener alguna forma de decir "estos tipos son casi iguales". En C89, por ejemplo, dos estructuras eran compatibles si eran idénticas pero su nombre era diferente. C99 parece haber cambiado eso. Citando del documento de fundamento c (lectura muy recomendable, por cierto!):

Las declaraciones de tipo de estructura, unión o enumeración en dos unidades de traducción diferentes no declaran formalmente el mismo tipo, incluso si el texto de estas declaraciones proviene del mismo archivo de inclusión, ya que las unidades de traducción son disjuntas. Por tanto, la Norma especifica reglas de compatibilidad adicionales para tales tipos, de modo que si dos de tales declaraciones son suficientemente similares, sean compatibles.

Dicho esto, sí, estrictamente, este es un comportamiento indefinido, porque su función do_stuff o alguien más llamará a su función con un puntero de función que tenga void*como parámetro, pero su función tiene un parámetro incompatible. Sin embargo, espero que todos los compiladores lo compilen y lo ejecuten sin quejarse. Pero puede hacerlo más limpio si tiene otra función que toma un void*(y lo registra como función de devolución de llamada) que simplemente llamará a su función real en ese momento.

Como el código C se compila con instrucciones que no se preocupan en absoluto por los tipos de punteros, está bastante bien usar el código que menciona. Tendría problemas cuando ejecutara do_stuff con su función de devolución de llamada y el puntero a otra cosa que no sea la estructura my_struct como argumento.

Espero poder hacerlo más claro mostrando lo que no funcionaría:

int my_number = 14;
do_stuff((void (*)(void*)) &my_callback_function, &my_number);
// my_callback_function will try to access int as struct my_struct
// and go nuts

o...

void another_callback_function(struct my_struct* arg, int arg2) { something }
do_stuff((void (*)(void*)) &another_callback_function, NULL);
// another_callback_function will look for non-existing second argument
// on the stack and go nuts

Básicamente, puede lanzar punteros a lo que quiera, siempre que los datos sigan teniendo sentido en tiempo de ejecución.

Si piensa en la forma en que funcionan las llamadas a funciones en C / C ++, empujan ciertos elementos en la pila, saltan a la nueva ubicación del código, ejecutan y luego abren la pila al regresar. Si los punteros de su función describen funciones con el mismo tipo de retorno y el mismo número / tamaño de argumentos, debería estar bien.

Por lo tanto, creo que debería poder hacerlo de forma segura.

Los punteros vacíos son compatibles con otros tipos de punteros. Es la columna vertebral de cómo funcionan malloc y las funciones mem ( memcpy, memcmp). Normalmente, en C (en lugar de C ++) NULLhay una macro definida como ((void *)0).

Mire 6.3.2.3 (elemento 1) en C99:

Un puntero a vacío se puede convertir ao desde un puntero a cualquier tipo de objeto o incompleto