[PATCH v8 1/3] jscript: Lookup and ref the named item's dispatch first, during interpretion.

Gabriel Ivăncescu gabrielopcode at gmail.com
Thu Mar 12 08:29:15 CDT 2020

Hi Jacek,

On 12/03/2020 13:02, Jacek Caban wrote:
> Hi Gabriel,
> On 11/03/2020 14:06, Gabriel Ivăncescu wrote:
>> @@ -2995,6 +3008,8 @@ HRESULT exec_source(script_ctx_t *ctx, DWORD 
>> flags, bytecode_t *bytecode, functi
>>               hres = create_named_item_script_obj(ctx, 
>> bytecode->named_item);
>>               if(FAILED(hres)) return hres;
>>           }
>> +        if(variable_obj == ctx->global)
>> +            variable_obj = bytecode->named_item->script_obj;
> This could be a separated patch. If in this case caller can't handle 
> variable_obj in many cases, maybe it shouldn't handle it at all. It 
> seems to me that we could get rid of that argument. exec_source has all 
> information needed to handle it by itself.
> Thanks,
> Jacek

I can split it of course, but I have some doubts when it comes to 
removing it. What should we do in function.c's InterpretedFunction_call?

A possible solution I came up with would be to add a new exec_flag, say 
EXEC_NEW_VARIABLE_OBJ and use it in InterpretedFunction_call -- then 
create it in exec_source if the flag is set.

In rest of cases, we take the frame->variable_obj if a frame is 
available, otherwise the ctx->global or named item's dispatch. All of 
this in exec_source of course, then we get rid of the parameter altogether.

Does that sound like a good approach?


More information about the wine-devel mailing list