-
Notifications
You must be signed in to change notification settings - Fork 117
Lua global "load" still accepts bytecode #182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, I think we might accept that the Lua But I agree that a (probably still unsafe) function to load bytecode from the Rust API seems reasonable.
|
This has been fixed as part of #236.
|
The docs suggest otherwise, though. In fact, that part of the docs seems outdated in general. How would one NOW go about turning Lua bytecode into a function? |
My mistake, there was a different issue with my code; the bytecode wasn't properly getting loaded in the proc macro I made that embeds said Lua code. As it would turn out, the docs are correct on that front. However the docs also suggest using eval without any generic parameters, which would suggest they are outdated. |
Hi. I think the examples are correct (at least the first couple I looked at), and would fail the doctests if they weren't. let add2: Function = lua_context.load(r#"
function(a)
return a + 2
end
"#).eval()?; Or I might not be looking at the same one as you! |
As I understand it, LuaContext's load function only accepts source code to ensure rust's safety semantics cannot be violated by a potentially unpredictable/(faulty behaving when presented with specially crafted input) C function.
Looks like from Lua itself, the global "load" function still accepts bytecode.
For a project of mine, I compile Lua scripts to bytecode, embed them in the project, and then load them back. Circumventing that limitation by tapping into globals() and retrieving the load function from there.
-> I think the ability to load bytecode should be removed from Lua globals, and maybe string.dump as well.
-> But, to compensate for that loss, I think both functions should be exposed to the rust API as unsafe {} calls?
Do you agree? If yes, I could submit a pull request.
The text was updated successfully, but these errors were encountered: