 |
lua-l archive |
|
|
||
|
|
De : Benoit Germain >There are also changes in luaconf regarding
default PATH and CPATH that I had to import in my copy of the Lua sources, but
that’s all. I guess that I can come up with the DLL myself,
it’s just that having it in the LfW distro to begin with would probably
help more people than just me J. >Now, I am confused about the bug I have: >If I trim my script to only use my module with
no other module loaded excepted for the standard Lua libraries, and to run it
against my LUA_USE_APICHECK statically linked Lua interpreter, the bug
disappears, and doesn’t >seem to be related to an API error after all.
The same test script run against the LfW interpreter seems to run into some
sort of C stack corruption since at some precise point in the execution of my
module, instruction jumps >to some irrelevant place when returning from __alloca_probe in a function’s prologue. Is there
something in the way LfW is built that could help me understand what is going
on? [BG] I guess I
“know” what was wrong: my module files are compiled as C++. The
functions that are part of the Lua binding (read: luaopen_ and functions referenced
in the luaL_Reg array) are extern “C”. My problem
arises when I call one the binding functions. At some point it calls a helper function,
where the problem manifests itself. The latter was initially compiled as C++
(and declared as such). Declaring it extern “C” restores the
expected behavior. Are there potential problems I should be aware of when
mixing “C” and C++ calling conventions? And why would this happen
only with the LfW DLL interpreter, and not the statically linked one I compiled
myself? PS: sorry in
advance for possible un-etiquette mail formatting, I don’t know of
Outlook will mangle this when I hit « send »… |