 |
lua-l archive |
|
|
||
|
Am 02.10.2012 21:32, schrieb Roberto Ierusalimschy:
With "safe" I meant "safe regarding the issue in my first post" giving me trouble with the different memory layout seen for global_state depending on the presence or absence of LUA_CORE. As I understand now any code of Lua itself which relies on the layout of e.g. global_state has LUA_CORE defined while any code not having LUA_CORE defined does not access this internal structure nor is doing any assumptions about it whatsoever (so in the end no problem arises).But whats the outcome of all this now? If I get the referred thread from Liam correctly and his explanation about LUA_CORE then I should in general define this compiler switch if I intend to do anything with the "inside mechanisms" of Lua to be on the safe side?! Is that correct?Not exactly. Lua is not structured for users to do stuff "inside" it. Lua has a very well-defined API, and Lua is organized towards people that use this API. Code in Lua either is inside this API or it is outside this API. You will notice that even Lua itself is very strict about this boundary. For instance, code inside the kernel does not calls API functions. No function in the Lua distribution uses the API and at the same time accesses inside mechanisms. Of course, you are welcome to do whatever you want with the inside mechanisms of Lua, but you must realize that there is no "safe side" in this case. If you are writing code inside the kernel, certainly you must define LUA_CORE (and you should not call API functions). If your code is outside the kernel, you do not define LUA_CORE (and do not access inside mechanisms). If your code is neither inside nor outside, probably you should define LUA_CORE but be very careful with what you do. -- Roberto
It's clear that any "inside poking" or self-made code relying on internals has a number of backdraws (e.g. compatibility, frustration ;-) etc.) and is nothing that can be supported by you or meets the original intention and spirit of Lua. (For any "serious" application I'd always stick to the official API unless I'd really really know, what I'm doing and have very good reasons for it.) I only did it out of curiosity to gain access to all loaded functions (or better prototypes) for debugging as I did not find an "official" way using the API to do that. But I have not yet really studied the already existing approaches to write debuggers (like zeroBrane etc.) to see if that can be done better.
Thanks for the insights and the tips. Greetings, Seppl