将MinGW excutable与由Visual C编译的库相关联的安全性如何.

像这里解释的东西.
http://www.codesynthesis.com/~boris/blog/2011/12/09/oci-mingw/

TL; DR“…因为OCI是一个C库,我们可以为VC,oci.lib取”官方“OCI导入库,将其重命名为libclntsh.a,我们为MinGW提供了OCI”

这是一场等待发生的事故吗？怎么可能出错？

最佳答案 这取决于.

AFAIK,没有什么可以阻止glibc和msvcrt在Windows上的同一进程中共存 – 在Linux上发生的相同的全局函数搜索不会发生在Windows上(每个动态导入都知道它来自哪个DLL – 函数不是合并在一个命名空间中).

但是,特定库可能存在问题.如果库指定例如“该函数返回一个指针,该指针应该在完成后用free()释放”,则需要使用正确的free释放它,即与分配的malloc()对应的那个.同样,如果函数声明“参数是一个缓冲区,将由函数释放free()”那么它必须与相应的malloc()一起分配.类似的问题适用于可以使用realloc()的地方.

例如,当使用针对不同版本的MSVCRT编译的DLL时,也会发生此问题. MSVCRT20.dll与MSVCRT40.dll.

这就是Windows库总是说明应该如何分配内存的原因.例如,参见CoTaskMemAlloc / CoTaskMemFree,LocalAlloc / LocalFree,HeapAlloc / HeapFree.文档可能声明“当不再需要时,必须使用CoTaskMemFree释放buffere”.或者他们可以提供他们自己的免费/分配对,例如“当不再需要时,必须使用SuperLibraryFreeBuffer释放返回的缓冲区”(内部可以简单地委托给CRT免费,但至少它将是免费的正确版本).

这是因为Windows始终是一个多语言平台,其中库可以用C以外的语言编写.今天我们可能习惯于Lisp,Pascal等是C运行时之上的层, – 大多数程序员可能会认为,即使在Pascal的情况下也不是这样 – 但并非总是如此：在C发明之前,Pascal在DEC计算机上被普遍使用了两年,并且作为每个人的Windows遗产知道与DEC有很多共同之处.早期版本的Windows在汇编程序中写得很大……有一个原因,你知道Windows 3标题中的“pascal”调用约定……