lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> On 20 Sep 2016, at 15:12, Christian N. <> wrote:
> Am 20.09.2016 um 15:01 schrieb Viacheslav Usov:
>> On Tue, Sep 20, 2016 at 2:42 PM, Christian N. <
>> <>> wrote:
>>> I thought of setjmp/longjmp too but the setjmp (pcall) and longjmp
>> (error) both happen in the same Lua DLL.
>> That does not matter. The problem in question is Lua built for runtime A
>> but is executed with runtime B. In runtime A, the size of jmp_buf is a;
>> in runtime B the size is b, and it may be possible that a != b. Then, if
>> a < b, runtime B's setjmp called by Lua will cause a buffer overrun, or,
>> if a > b, runtime B's longjmp will not restore some of the state
>> required by Lua compiled for runtime A.
>> Secondly, setjmp, being a macro in either A or B or both, may do
>> something not compatible with the other runtime's longjmp even if a == b.
>> Cheers,
>> V.
> Of course if a binary was compiled against CRT A but is dynamically linked against CRT B then all bets are off.
> But normally incompatible runtimes will have different DLL names (msvcr110.dll, msvcr120.dll, etc.). Thus when you compile a DLL against CRT A and your executable against CRT B then both CRTs will be loaded at runtime and the DLL and the main executable will both use their own ones independently.
> ‒ Christian

This is simply not true, read up on the MSDN link I send earlier in the thread, where Microsoft discusses the potential problems of using multiple runtime (don’t take my word for it, better take theirs, they wrote the stuff).

Repeating; mixing runtime ‘seems’ to work, until it doesn’t. You’ll get sporadic and hard to trace crashes. Search the archives, plenty of others went before you…