Lua C API questions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua C API questions

Dibyendu Majumdar
Hi,

One of the things I implemented in Ravi is optional static typing so
the compiler enforces types on local variables annotated with type
information. I am now starting to assess the impact on the C API and I
immediately noticed that the API provides lua_xmove() which can break
the type system as it knows nothing about the expected types.

I am looking into the C API code and will eventually figure things out
but it would be a huge help if following questions could be answered:

1. I think it is invalid for a C function to amend the stack beyond
what it is given to it - but I see that there is only an assert to
this effect which obviously is an optional check. My question is why
is this check an assert and not something stronger like a runtime
check?

2. Functions like luax_move() that copy stack values - are there use
cases where such functions could amend the values in local variables
of a Lua function? I take it that the Debug API would allow this to
happen - but is there any other scenario where this can happen?

3. Is it the case that all other APIs go via the core API in lapi.c,
so that if I focus on this then it will resolve any issues with the
rest of the APIs?


Thanks  and Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua C API questions

Roberto Ierusalimschy
> 1. I think it is invalid for a C function to amend the stack beyond
> what it is given to it - but I see that there is only an assert to
> this effect which obviously is an optional check. My question is why
> is this check an assert and not something stronger like a runtime
> check?

(I am not sure I understood your concept of "stronger", but anyway...)

C is a different world from Lua. Almost anything can go very wrong, and
most of these things are uncheckable. For instance, there is no way to
check that a lua_State passed as the first argument to any API function
has not been closed. Moreover, we assume that C code in Lua libraries
are more stable and more well tested than regular Lua code. In the end,
we think it is not worth to pay a performance price for this somewhat
"illusion" of safety.

>

> 2. Functions like luax_move() that copy stack values - are there use
> cases where such functions could amend the values in local variables
> of a Lua function? I take it that the Debug API would allow this to
> happen - but is there any other scenario where this can happen?

No. Only the debug API can interfere with other function's stuff.


> 3. Is it the case that all other APIs go via the core API in lapi.c,
> so that if I focus on this then it will resolve any issues with the
> rest of the APIs?

All API go via the core API, but not all the core API is in lapi.c.
There are a few functions in ldo.c and some in ldebug.c. **All are
clearly marked with *LUA_API***. No function without a LUA_API should
ever be called from outside the core. (No function with a LUA_API
should ever be called from inside the core, too; this rule is being
broken sometimes, but in very controled ways ;-) Anyway, it does not
concern us here.).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua C API questions

Dibyendu Majumdar
On 5 April 2015 at 14:36, Roberto Ierusalimschy <[hidden email]> wrote:

>> 1. I think it is invalid for a C function to amend the stack beyond
>> what it is given to it - but I see that there is only an assert to
>> this effect which obviously is an optional check. My question is why
>> is this check an assert and not something stronger like a runtime
>> check?
>
> (I am not sure I understood your concept of "stronger", but anyway...)
>
> C is a different world from Lua. Almost anything can go very wrong, and
> most of these things are uncheckable. For instance, there is no way to
> check that a lua_State passed as the first argument to any API function
> has not been closed. Moreover, we assume that C code in Lua libraries
> are more stable and more well tested than regular Lua code. In the end,
> we think it is not worth to pay a performance price for this somewhat
> "illusion" of safety.

Ok, understood.

>
>> 2. Functions like luax_move() that copy stack values - are there use
>> cases where such functions could amend the values in local variables
>> of a Lua function? I take it that the Debug API would allow this to
>> happen - but is there any other scenario where this can happen?
>
> No. Only the debug API can interfere with other function's stuff.
>

That's very helpful to know - thank you!

>
>> 3. Is it the case that all other APIs go via the core API in lapi.c,
>> so that if I focus on this then it will resolve any issues with the
>> rest of the APIs?
>
> All API go via the core API, but not all the core API is in lapi.c.
> There are a few functions in ldo.c and some in ldebug.c. **All are
> clearly marked with *LUA_API***. No function without a LUA_API should
> ever be called from outside the core. (No function with a LUA_API
> should ever be called from inside the core, too; this rule is being
> broken sometimes, but in very controled ways ;-) Anyway, it does not
> concern us here.).
>

Excellent - really appreciate the insight. Working with Lua is so
rewarding exactly because everything seems to have been carefully
thought through.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua C API questions

Dibyendu Majumdar
Is it acceptable to call luaG_runerror() in an API function like
lua_rawset() or lua_rawseti()?
The scenario is that the value or key is invalid (i.e. allowing it
would corrupt the type system).

Thanks and Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua C API questions

Rena
On Fri, Apr 10, 2015 at 10:24 PM, Dibyendu Majumdar
<[hidden email]> wrote:
> Is it acceptable to call luaG_runerror() in an API function like
> lua_rawset() or lua_rawseti()?
> The scenario is that the value or key is invalid (i.e. allowing it
> would corrupt the type system).
>
> Thanks and Regards
> Dibyendu
>

Why do that as opposed to lua_error() or luaL_error()?

--
Sent from my Game Boy.

Reply | Threaded
Open this post in threaded view
|

Re: Lua C API questions

Dibyendu Majumdar
On 11 April 2015 at 03:30, Rena <[hidden email]> wrote:
>> Is it acceptable to call luaG_runerror() in an API function like
>> lua_rawset() or lua_rawseti()?
> Why do that as opposed to lua_error() or luaL_error()?

Calling luaL_error() breaks the rule - core API cannot depend upon non-core API.
Calling lua_error() breaks the rule 'No function with a LUA_API should
ever be called from inside the core, too'

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Lua C API questions

Roberto Ierusalimschy
In reply to this post by Dibyendu Majumdar
> Is it acceptable to call luaG_runerror() in an API function like
> lua_rawset() or lua_rawseti()?

Yes.

-- Roberto