Re: Lua library

[Philipp Janda <siffiejoe@...>]

Am 17.08.2016 um 06:07 schröbte Peter Chen:
> Hi,

Hi!

>   I am pretty new to Lua. I am trying to use it as a policy language
> in ARM TrustZone. I want to compile it into my application directly
> from source. I am using OPTEE-OS which has a minimal libc. I took a
> look at the Makefile in the src/. It seems that there is CORE_O and
> LIB_O for building liblua.
>
>   My use case is that a part of a file will be Lua script. My C
> application will parse this file and feed the chunks in a buffer to
> Lua interpreter through the C API.
>
>    I have the following questions:
>
>    1) Is libLua the C API I develop against (can it do everything that
> is in the Programming in Lua PART IV)? If not....the only object files
> it doesn't include is lua.c and luac.c...so...

Yes. `liblua.a` contains the Lua C API (amongst others). `lua.c` and 
`luac.c` are essentially sample programs that use `liblua.a`.

>    2) I just require the interpreter and some of the standard
> libraries. I do not need coroutine, package, io, module, os, utf8 or
> debug std library. To remove these, which object files in LIB_O should
> I leave out? I can see lcorolib.o, loadlib.o, oslib.o, but the rest is
> hard to do a one-to-one match. Would this break Lua build in any way?

You also have to modify the static array in `linit.c`.

Here is the list for Lua 5.3.3:

*   lbaselib.c  => Lua base library
*   lbitlib.c => Lua bit32 module
*   lcorolib.c => Lua coroutine module
*   ldblib.c => Lua debug module
*   liolib.c => Lua io module
*   lmathlib.c => Lua math module
*   loslib.c => Lua os module
*   lstrlib.c => Lua string module
*   ltablib.c => Lua table module
*   lutf8lib.c => Lua utf8 module
*   loadlib.c => Lua package module and `require` function

You can remove individual Lua standard modules without problems (or you 
can add your own). The only LIB_O files you'll probably need are 
`lauxlib.o` for all `luaL_*` API functions (like `luaL_loadbufferx`) and 
`linit.o` (or a replacement) which defines which standard libraries 
should be loaded.

>     3a) I see luaL_loadbufferx() as the C API to give a buffer to Lua
> interpreter. I am wondering what the semantic is. Does the buffer you
> give have to be a complete Lua script? Or can you repeatedly feed it
> line-by-line, character-by-character?

It has to be a complete Lua chunk. If your Lua code arrives piecemeal, 
you can use `lua_load()`. However, this is still pull-mode. If you want 
push-mode, you'll have to do your own buffer handling (you can use the 
`luaL_Buffer` API) and call `luaL_loadbuffer(x)` when your code is complete.

>     3b) Does it run the script automatically or is there a function I
> have to call to evaluate the script in the buffer?

It compiles the given code into a function that is left at the top of 
the stack. You have to call this function yourself using 
`lua_(p)call(k)`, or you can do anything else you'll want to do with a 
Lua function (passing it around, making a coroutine, ...).

>     3c) If it runs automatically, what if my script has functions
> also, how do I call a specific Lua function to run in the script?

It doesn't run automatically, *you* have to run it. After you've done 
that, you can access its return values, query the globals it has set, 
and/or call the (global) functions your script has defined.

>     3d) Once I run luaL_loadbufferx(), how do I get the return value
> of the Lua script?

The return values are on the Lua stack after your `lua_(p)call(k)` call.

>     I really only need a minimal version of the Lua. Just the
> interpreter, C API, auxiilary library  base, string, table, and math
> standard libraries. The reason I want to remove unnecessary parts is
> that I am not sure what OPTEE is missing in its libc (so far I think I
> might be missing setjmp/longjmp).

This is a tough one! `setjmp` and `longjmp` are essential for error 
handling and coroutine yielding. You could use C++ exceptions or some 
equivalent POSIX functions instead, but you definitely need something 
like this. See `ldo.c` for available options.

> Thanks.
>
> Peter

HTH,
Philipp