lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Lua 5.2 (without the IO library) is implemented in the SAS language (SAS institute), used inside restricted enterprise data environments by tens of thousands of programmers globally, myself included.

Perhaps if there was further support for no-syscall, we’d get a much desired Lua upgrade!

/Allan

On Wed, 27 Feb 2019 at 00:45, Stojan Dimitrovski <sdimitrovski@gmail.com> wrote:
Ah, OK I see. Well in that case let me present why I think Lua should
include minimal support for running in a no-syscall system.

Who'd need this?

This would allow embedding Lua inside very restricted environments.
I'm personally using it in an Intel SGX project.

How to implement it?

It's actually pretty easy to do in the Lua 5.3.5 codebase. What I've
done is section out all IO use with the LUA_NOIO macro. This does
restrict parts of the standard library a bit too restrictively and
would require reimplementation by the embedder for the use case. Aside
from the IO lib, almost all of the baselib needs to be reimplemented
-- modules and all that. So that should be probably thought about more
carefully. There are a few places that use locale.h, time.h and
similar, but they are already controllable through defining macros.
The lua.c and luac.c files are obviously unusable, so those just
shouldn't make it in the embedder's Makefile.

Improving on the existing implicit IO

So Lua has a few of these helper functions that actually do IO
implicitly. lua_writerror, and friends, are macros that write directly
with fprintf or fwrite to stdout or stderr. These can all be redefined
to customize, though a problem I see with them is that those macros
are less flexible from an embedder's point of view. As a first step
toward improving them, I'd just add the lua_State that is calling them
as an argument (even if it's unused in the standard Lua). What this
will allow is implementing virtual IO channels in restricted
environments. Basically, Lua should provide at least the lua_State
whenever it's doing any kind of operation.

One can easily make a case for a virtual IO system, but I think that's
not necessary presently, as this kind of work is fairly rare.




On Tue, Feb 26, 2019 at 1:10 AM Jonathan Goble <jcgoble3@gmail.com> wrote:
>
> On Mon, Feb 25, 2019 at 6:35 PM Stojan Dimitrovski <sdimitrovski@gmail.com> wrote:
>>
>> I was wondering, if I clean it up a bit, how do I submit it as an
>> actual patch to Lua itself? I also see some other places the IO
>> situation with Lua can be improved, so I'd also like to improve on
>> that as well.
>>
>> Thanks,
>> Stojan
>
>
> Lua does not accept patches. Although Lua is open source, it is not open developed. The Lua team (Roberto, Luiz, and one other person who never posts here) make all decisions and write all code for Lua themselves. They do take community feedback into consideration via this mailing list, but if they like an idea, they will write their own code to implement it rather than accepting someone else's patch.
>
> Also, the 5.4 development cycle is underway, and massive changes have been made since 5.3.5. You can take a look at that work at https://github.com/lua/lua, which is an unofficial mirror of the Lua repository as seen by the Lua team. It is always slightly out-of-date as commits are not mirrored in real-time. Pull requests are not accepted for the reasons discussed in the previous paragraph.



--
Stojan Dimitrovski
http://stojan.me