Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows

[Tacvek]

----- Original Message ----- 
From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: <address@hidden>
Sent: Sunday, July 16, 2006 4:26 PM
Subject: Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows



> I looked at Lua how it processes luaL_error. luaconf.h offers 3 methods
> for LUAI_THROW/LUAI_TRY: C++ exceptions, _longjmp/_setjmp and
> longjmp/setjmp. Linux and Mac use _longjmp/_setjmp, Windows uses
> longjmp/setjmp independent of the MingW exception method (SJLJ, DW2).

Hmm... That seems to make sense. I do find it odd that Lua would use _setjmp 
and _longjmp directly.
Normally it is a good idea to not use compiler internal calls directly.  I 
would assume that
GCC on linux and Mac map setmp/longjmp to the internal compuiler versions 
anyway, so it does not seem
like there is much to gain besides saving a fraction of a milisecond of 
compilation time.


> The MingW setjmp.h looks strange: setjmp is mapped to _setjmp, _longjmp
> does not exist. The comment to the used buffer is funny:
> > /*
> >  * The buffer used by setjmp to store the information used by longjmp
> >  * to perform it's evil goto-like work. The size of this buffer was
> >  * determined through experimentation; it's contents are a mystery.
> >  * NOTE: This was determined on an i386 (actually a Pentium). The
> >  *       contents could be different on an Alpha or something else.
> >  */
> > #define _JBLEN 16

That does not look good. I think comments like that in the source of a 
compiler is usually a bad sign.
I'm a bit curious why the linux longjmp implementation is not used on 
Windows. I assume that
windows somehow manages to prevent it from working.

It is probably not a great idea to be using longjmp anyway. Based on my 
reading of the C standard
There is a decent chane that a compiler will not clean up properly under 
certain circumstances. This can be
even worse under C++ because the compiler has to take care of a lot more 
housekeeping. If the compiler managed to
botch this in some way or other a segfault is exactly what I would expect.


> One experiment would be to compile Lua as C++ - this would guarantee the
> same exception mechanism being used in Enigma and Lua. (Some Enigma
> sources would need minor adaptation. No idea about tolua++' exception 
> dependency). The effects on SJLJ and DW2 would be interesting.

Does tolua++ touch exceptions or lua errors in any way? I don't think it 
uses pcall (protected call) so the lua errors would propgate back up to 
Enigma.
I'm not sure that many changes would be needed to enigma's source. Lua would 
not be expecting us to catch these exceptions.
It would catch them internally and indicate the error in the same way as 
normal. So the key would be not accidentally catching lua's exceptions
If needed we can catch them explicitly and rethrow them so that they get 
back to Lua.



> On the other hand a Visual Studio Express compilation should use
> Microsoft SEH. Another chance to bypass tan expection handling problem.
I also have a full install of VS 2005, but I do prefer being able to cross 
compile, because everything runs so much
nicer. Bash scripting is far more powerful than CMD.exe scripting.