punteros de función y número indeterminado de argumentos en C++

Question

me encontré con el siguiente trozo de code.Imagine raro que tiene la siguiente typedef:

typedef int (*MyFunctionPointer)(int param_1, int param_2); 

Y luego, en una función, que están tratando de ejecutar una función desde un archivo DLL de la siguiente manera:

LPCWSTR DllFileName; //Path to the dll stored here 
LPCSTR _FunctionName; // (mangled) name of the function I want to test 

MyFunctionPointer functionPointer; 

HINSTANCE hInstLibrary = LoadLibrary(DllFileName); 
FARPROC functionAddress = GetProcAddress(hInstLibrary, _FunctionName); 

functionPointer = (MyFunctionPointer) functionAddress; 

//The values are arbitrary 
int a = 5; 
int b = 10; 
int result = 0; 

result = functionPointer(a, b); //Possible error? 

el problema es que no hay ninguna manera de saber si el functon cuya dirección nos dieron, con LoadLibrary toma dos enteros arguments.The nombre de la DLL es proporcionada por el usuario en tiempo de ejecución, se enumeran los nombres de las funciones exportadas y el usuario se toma contacto con el que lo prueba (nuevamente, en tiempo de ejecución: S: S). Entonces, al hacer la llamada de función en la última línea, ¿no estamos abriendo la puerta a posibles daños en la pila? Sé que esto compila, pero ¿qué tipo de error de tiempo de ejecución va a ocurrir en el caso de que estemos pasando argumentos incorrectos a la función a la que estamos apuntando?

Answer 1

Hay tres errores que se me ocurre si el esperado y el número o el tipo de parámetros y la convención de llamada utilizados difieren:

• si la convención de llamada es diferente, los valores de parámetros erróneos serán leídos
• si la función realmente espera más parámetros que los dados, los valores aleatorios se usarán como parámetros (te dejaré imaginar las consecuencias si los punteros están involucrados)
• En cualquier caso, la dirección de devolución será completa, por lo que el código aleatorio con el azar los datos se ejecutarán tan pronto como la función regrese.

En dos palabras: Undefined behavior

Answer 2

Me temo que no hay forma de saberlo: el programador debe conocer el prototipo de antemano al obtener el puntero de la función y usarlo.

Si no conoce el prototipo de antemano, entonces supongo que debe implementar algún tipo de protocolo con la DLL, donde puede enumerar los nombres de las funciones y sus parámetros llamando funciones conocidas en la DLL. Por supuesto, la DLL debe escribirse para cumplir con este protocolo.

Answer 3

Generalmente, si llama a LoadLibrary y GetProcByAddrees, tiene documentación que le indica el prototipo. Incluso más comúnmente como con todos los windows.dll se le proporciona un archivo de cabecera. Si bien esto causará un error si es incorrecto, generalmente es muy fácil de observar y no el tipo de error que se colará en la producción.

Answer 4

No lo creo, es una buena pregunta, la única disposición es que DEBE saber cuáles son los parámetros para que funcione el puntero a la función, si no lo hace y rellena los parámetros a ciegas y lo llama, se estrellará o saltará al bosque para no volver a verse nunca más ... Depende del programador transmitir el mensaje sobre lo que espera la función y el tipo de parámetros, afortunadamente podría desmontarlo y descubrirlo al mirar la pila puntero y dirección esperada a través del 'puntero de pila' (sp) para averiguar el tipo de parámetros.

Usando PE Explorer, por ejemplo, puede averiguar qué se utilizan las funciones y examinar el volcado desmontaje ...

Espero que esto ayude, Saludos cordiales, Tom .

Answer 5

La mayoría de los compiladores C/C++ tienen la persona que llama configura la pila antes de la llamada, y luego reajusta el puntero de la pila. Si la función llamada no utiliza punteros o argumentos de referencia, no habrá corrupción de memoria, aunque los resultados no tendrán ningún valor. Y como dice la repetición, los errores de puntero/referencia casi siempre aparecen con un mínimo de prueba.

Answer 6

O bien se bloqueará en el código DLL (ya que se pasó los datos corruptos), o: Creo que Visual C++ agrega código en las compilaciones de depuración para detectar este tipo de problema. Dirá algo así como: "El valor de ESP no se guardó en una llamada de función", y apuntará al código cerca de la llamada. Ayuda, pero no es totalmente robusto: no creo que le impida pasar el argumento incorrecto pero del mismo tamaño (por ejemplo, int en lugar de un parámetro char * en x86). Como dicen otras respuestas, solo tienes que saber, realmente.

Answer 7

Si Es una función __stdcall y que han dejado el nombre de mangling intactos (tanto grandes condiciones, pero ciertamente posible no obstante) el nombre tendrá @nn al final, donde nn es un número. Ese número es el número de bytes que la función espera como argumentos, y borrará la pila antes de que regrese.

Por lo tanto, si es una preocupación importante, puede ver el nombre sin procesar de la función y verificar que la cantidad de datos que está colocando en la pila coincida con la cantidad de datos que eliminará de la pila.

Tenga en cuenta que esto sigue siendo solo una protección contra Murphy, no contra Maquiavelo. Cuando está creando una DLL, puede usar un archivo de exportación para cambiar los nombres de las funciones. Esto se usa con frecuencia para quitarle el nombre a los cambios, pero estoy bastante seguro de que también le permitirá cambiar el nombre de una función de xxx @ 12 a xxx @ 16 (o lo que sea) para engañar al lector sobre los parámetros que espera.

Editar: (principalmente en respuesta al comentario de msalters): es cierto que no puede aplicar __stdcall a algo así como una función miembro, pero ciertamente puede usarlo en cosas como funciones globales, ya sea que estén escritas en C o C++.

Para cosas como las funciones de miembro, el nombre exportado de la función se truncará. En ese caso, puede usar UndecorateSymbolName para obtener su firma completa. Usar eso no es algo trivial, pero tampoco exageradamente complejo.

Answer 8

No hay una respuesta general. El Estándar exige que se den ciertas excepciones en ciertas circunstancias, pero aparte de eso describe cómo se ejecutará un programa conforme, y algunas veces dice que ciertas violaciones deben resultar en un diagnóstico. (Puede haber algo más específico aquí o allá, pero ciertamente no recuerdo ninguno.)

Lo que el código está haciendo no está de acuerdo con el Estándar, y dado que hay un molde, el compilador tiene derecho a seguir adelante y hacer cualquier cosa estúpida que el programador quiere sin quejarse. Por lo tanto, esto sería un problema de implementación.

Puede consultar la documentación de implementación, pero probablemente tampoco esté allí. Puede experimentar o estudiar cómo se realizan las llamadas de función en su implementación.

Desafortunadamente, la respuesta es muy probable que arruine algo sin ser inmediatamente obvio.