 |
lua-l archive |
|
|
||
|
Paul K wrote:
The question is this: what are the real reasons behind advice to not mix DLLs compiled with different compilers? Why is everything working correctly (even socket.select), but in some (quite rare, but still reproducible) cases things go wrong?
MinGW and Visual Studio use different C runtimes (with the exception of the combination of MinGW and Visual Studio 6).
Lua file objects wrap C "FILE" streams. Lua Socket sockets are (I assume) also implemented on top of these. It probably works mostly for simple cases because the Visual Studio C runtime is unlikely to have changed its' internal memory layout substantially between versions, but occasionally you'll hit on a corner case. For example, if Luasocket needs to get the Win32 HANDLE behind a "FILE" object, it will call _fdnum in its' own C library (which probably works because of the same structure layout) to get the file descriptor number, followed by _get_osfhandle to convert the UNIX-style FD number into a Win32 HANDLE.
And this is where it goes wrong, because every C runtime has its own file descriptor table, so LuaSocket gets the wrong handle. If you're "lucky" (for some definition of lucky) LuaSocket gets the wrong handle and things still (sort of, but not really) work, and if you're "unlucky" (which in some regards is more lucky, because at least the problem is immediate) you crash (perhaps because you go past the end of the file descriptor array in the C library).
Whatever the result, it occurs whenever you try to interact with things at the C library/C++ library layer between different DLLs compiled with different runtime libraries on Windows.