[PATCH v7 3/4] jscript: Don't lookup global members for bytecodes with a named item.

[Jacek Caban]

On 10.03.2020 18:19, Gabriel Ivăncescu wrote:
> On 10/03/2020 17:44, Jacek Caban wrote:
>> Hi Gabriel,
>>
>> On 10.03.2020 14:04, Gabriel Ivăncescu wrote:
>>> Signed-off-by: Gabriel Ivăncescu<gabrielopcode at gmail.com>
>>> ---
>>>   dlls/jscript/engine.c        | 4 +++-
>>>   dlls/jscript/tests/jscript.c | 2 +-
>>>   2 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/dlls/jscript/engine.c b/dlls/jscript/engine.c
>>> index 3e32ea0..c8d33cb 100644
>>> --- a/dlls/jscript/engine.c
>>> +++ b/dlls/jscript/engine.c
>>> @@ -3034,6 +3034,8 @@ HRESULT exec_source(script_ctx_t *ctx, DWORD 
>>> flags, bytecode_t *bytecode, functi
>>>       }
>>>       if(flags & (EXEC_GLOBAL | EXEC_EVAL)) {
>>> +        BOOL lookup_globals = (flags & EXEC_GLOBAL) && 
>>> !bytecode->named_item;
>>> +
>>>           for(i=0; i < function->var_cnt; i++) {
>>>               TRACE("[%d] %s %d\n", i, 
>>> debugstr_w(function->variables[i].name), 
>>> function->variables[i].func_id);
>>>               if(function->variables[i].func_id != -1) {
>>> @@ -3045,7 +3047,7 @@ HRESULT exec_source(script_ctx_t *ctx, DWORD 
>>> flags, bytecode_t *bytecode, functi
>>>                   hres = jsdisp_propput_name(variable_obj, 
>>> function->variables[i].name, jsval_obj(func_obj));
>>>                   jsdisp_release(func_obj);
>>> -            }else if(!(flags & EXEC_GLOBAL) || 
>>> !lookup_global_members(ctx, function->variables[i].name, NULL)) {
>>> +            }else if(!lookup_globals || !lookup_global_members(ctx, 
>>> function->variables[i].name, NULL)) {
>>>                   DISPID id = 0;
>>>                   hres = jsdisp_get_id(variable_obj, 
>>> function->variables[i].name, fdexNameEnsure, &id);
>>
>>
>> I think that the real problem is that we pass wrong variable_obj to 
>> exec_source in this case.
>>
>>
>> Thanks,
>>
>> Jacek
>>
>
> Sorry, I don't understand what you mean. The function 
> "lookup_global_members" must not be called if we're in a named item 
> context, since those are part of the global scope only, as evidenced 
> by tests.
>
> I don't see how variable_obj is used anywhere before that, except to 
> assign it to the named item dispatch. It has to be done here, because 
> the dispatch is potentially created here (on demand) so it may not 
> exist before at the caller site. 


Okay, the patch is fine.


Thanks,

Jacek