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?
Thanks, Gabriel