RE: PATCH: How to handle CallInfo func field safely?

[Tatsuhiro Aoshima <tatsuhiro.aoshima.md@...>]

> In the other call (inside 'ccall'), there is a call to 'luaD_precall'
> that does access 'cl', but I don't see a cheap way to return that.

Of course, so I proposed the patch in order to not check like that every time.

> To remove that assignment, making 'cl' a parameter, would only spread that cast to several other places.

What do you mean this?

。:+* ゜ ゜゜ *+:。:+* ゜ ゜゜ *+:。:+* ゜ ゜゜ *+:。
Tatsuhiro Aoshima
NTT Secure Platform Laboratories
Phone: +81 422 59 3261 [JPN: (0422) 59 3261]


-----Original Message-----
From: Roberto Ierusalimschy <roberto@inf.puc-rio.br> 
Sent: Thursday, April 22, 2021 1:54 AM
To: Lua mailing list <lua-l@lists.lua.org>
Subject: Re: PATCH: How to handle CallInfo func field safely?

> That said, now that you mention it really is a bit strange that it 
> does a straight cast with clLvalue, without any checking. I wonder if 
> it would make sense to have the `cl` be one of the parameters to 
> luaV_execute. The places that call luaV_execute are all places that 
> have checked the type tag of the function object and have the `cl` at hand.

luaV_execute is called in three places (all of them in ldo.c). It seems that in none of them 'cl' is readly available. In two of
them (when resuming and unrolling a coroutine), Lua uses a bit in CallInfo to check whether the function is a Lua function, with no
access to 'func'. In the other call (inside 'ccall'), there is a call to 'luaD_precall'
that does access 'cl', but I don't see a cheap way to return that.

Moreover, whe luaV_execute restarts (returning from or calling another function), it also needs to update its 'cl'. To remove that
assignment, making 'cl' a parameter, would only spread that cast to several other places.

-- Roberto