Ninguna respuesta existente es correcta: dado lo siguiente en Windows: tiene dos DLL, cada una está estáticamente vinculada con dos versiones diferentes de las bibliotecas estándar de C/C++.
En este caso, no debe pasar punteros a las estructuras creadas por la biblioteca estándar de C/C++ en una DLL a la otra. La razón es que estas estructuras pueden ser diferentes entre las dos implementaciones de la biblioteca estándar de C/C++.
La otra cosa que no debes hacer es liberar un puntero asignado por nuevo o malloc de una DLL que fue asignada en la otra. El administrador de montón también puede implementarse de manera diferente.
Tenga en cuenta que puede utilizar los punteros entre los archivos DLL, solo apuntan a la memoria. Lo gratuito es el problema.
Ahora, puede encontrar que esto funciona, pero si lo hace, entonces usted es solo suerte. Es probable que esto le cause problemas en el futuro.
Una posible solución a su problema es vincular dinámicamente al CRT. Por ejemplo, puede vincular dinámicamente a MSVCRT.DLL. De esa forma, su DLL siempre usará el mismo CRT.
Nota, sugiero que no es una buena práctica pasar estructuras de datos CRT entre archivos DLL. Es posible que desee ver si puede factorizar mejor las cosas.
Nota, no soy un experto en Linux/Unix, pero también tendrá los mismos problemas en esos sistemas operativos.
Entiendo los problemas - Estoy pidiendo respuestas a este problema :) Esperaba una solución que no suponga cambiar la API C existente (con FILE * en la firma, etc.), pero parece que no existe ¿No puedo garantizar que todo esté vinculado al mismo tiempo de ejecución de C? Aunque el problema es teóricamente el mismo en Unix, rara vez es un problema porque solo hay un tiempo de ejecución de C. Nunca tuve un solo problema al pasar FILE *, descriptores de archivos en Unix entre bibliotecas: muchos C APIS están diseñados de esta manera y funcionan sin problemas en esos sistemas operativos. –
Si tener FILE * en la firma de la API no es una buena práctica, ¿cómo se maneja en absoluto el flujo de archivos? ¿Necesita exportar las funciones para abrir y cerrar los archivos si la DLL que llama tiene algunas funciones que llaman internamente a fprintf y otras funciones que esperan FILE *? –
He sugerido una solución :) No establezca un enlace estático con el CRT. enlace a MSVCRT.DLL. Me sorprendería mucho si se garantizara que todas las bibliotecas CRT en Linux, Unix o MAC funcionarían sin fallas. Creo que has tenido suerte allí también. – Foredecker