 |
lua-l archive |
|
|
||
|
Am 20.04.2014 02:08 schröbte Coroutines:
On Sat, Apr 19, 2014 at 4:59 PM, Philipp Janda <siffiejoe@gmx.net> wrote:I don't see the issue for lightuserdata either, you can just `print` it. So I was talking about full userdata and "transferring data between lua states".Didn't know you could just print it :-) I don't handle lightuserdata often..
You can print everything (and in case of lightuserdata it even tells you what you want to know -- the pointer value).
Just viewing is fine. The problems start when you transfer a userdata with an embedded pointer in it and use it in the other lua state.If we are arguing over whether this function should exist upstream, I don't think this point should count against it. It's outside the scope of simply viewing the contents of a userdata. :> Whether you understand the risks of using those contents and take measures to mitigate it -- that's up to you :> I'm only arguing because it seems like you'd rather not see this become part of Lua because of the risk of how it can be misused ..
If you want to use this function for transferring state, you already work in C code and you can put this 10 line function (and the inverse) in there yourself -- no reason it should be in Lua. If you want to debug your own userdata from within Lua, you already work in C code and you can put this 10 line function in there yourself -- no reason it should be in Lua. (I would suggest a nice `__tostring` function however ...) If you really debug third-party userdata from within Lua, you have my sympathies, but you are obviously familiar enough with C that you can write a small C module to do that for you, and I think there are lots of functions that are more useful to more people ...
Everything IMHO, of course. Philipp