[PATCH v2 2/3] jscript: Don't execute any functions if script state does not allow it.

Gabriel Ivăncescu gabrielopcode at gmail.com
Wed Jun 1 08:48:26 CDT 2022

On 01/06/2022 03:07, Jacek Caban wrote:
> On 5/31/22 16:56, Gabriel Ivăncescu wrote:
>> Instead of only interpreted functions. Property retrievals or setters are
>> allowed though, as long as they are not accessors.
>> Signed-off-by: Gabriel Ivăncescu<gabrielopcode at gmail.com>
>> ---
>> Note that native GetDispID seem to fail when retrieving builtin/prototype
>> functions (?) if script is uninitialized, but retrieving the DISPID 
>> before and
>> using it after it's uninitialized still works, though (that's what the 
>> tests
>> do). I don't think it's worth replicating this GetDispID quirk for the 
>> moment.
> I'm not really concerned about GetDispID quirks, but implication of your 
> choice for the next patch. I think that releasing objects sooner is 
> better, so it would be good to have a better argument for moving that. 
> Your reasoning there is based on details of how you decided to not 
> follow native here.
> More generally, creating function objects in response for property get 
> is an implementation detail that supposed to be transparent. If it's 
> causing problems elsewhere, I'd first look at making it more 
> transparent. In this case, maybe we should create function objects 
> sooner, in response to GetDispID. This would both match all tests and 
> allow us to release function constructor sooner.
> Jacek

Right, but how is releasing such objects not an implementation detail as 
well? The thing is, there's a very rare crash in FFXIV Launcher when 
logging in that happens when some proxy prototype tries to obtain the 
object prototype, which for some reason is NULL (suggesting 
uninitialized script). I haven't been able to investigate it in depth 
since I wasn't able to reproduce it since then. But it would be neatly 
solved by this as well without adding any complexity.

What's such a big deal about releasing them later? It's not like scripts 
stay that long in the uninitialized state, nor does it complicate the 
code, and it's an implementation detail anyway. If the function object 
was created earlier, it would still use the same function object, so the 
end result is exactly the same.

On the other hand, obtaining the function object on dispid seems like 
too much work for no real gain. On top of work, that would also lose all 
the current optimizations with builtins (which are only retrieved now on 
PROPERTYGET, which is pretty rare—most of the time they're just called 
directly, while looking up their DISPIDs happens all the time). I'm 
definitely not certain that's a good idea.

More information about the wine-devel mailing list