lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 2019-06-27 8:47 p.m., Philippe Verdy wrote:
Your example is counter intuitive: why does the last assert(foo==3) has to be true (the outer scope was modified by the double-inner  scope use of "unset": why does then foo=3 would not affect instead the middle scope and then throw an error on assert(foo==2)? If that "assert(foo==2)" passes then the "unset foo" has no effect than just being equivalent to "local foo -- =nil" and then the last assertion assert(foo=3) should fail because foo is still equal to 1. Your idea would create a security havoc where programs can unhide the protection layers to get access to internal variables being normally inacessessible to them. The only safe behavior would be that "unset foo" is like "local foo" (so "unset" is not necessary at all) but still different from the assignment "foo=nil" which overrides the value of the same variable in scope (only the former value of that variable will be closed and garbage collected, but the scope does not change: that same variable continues to used in other references, notably in other function closures). Alloing a program to control the scoping of outer varisables they did not declare themselves is a crazy and dangerous idea.
If you're concatenating attacker code into your program code, you have bigger issues. (see: SQL injection) 

You cannot unset globals and upvalues. It is an error.
Le mer. 26 juin 2019 à 22:27, Soni "They/Them" L. <fakedme@gmail.com <mailto:fakedme@gmail.com>> a écrit : 

    okay so a while back I talked about this "unset foo" idea, that would
    allow you to get through to shadowed names.

    the example I gave was basically:

    local foo = 1
    do
       local foo = 2
       do
         unset foo
         foo = 3
       end
       assert(foo == 2)
    end
    assert(foo == 3)

    (I don't remember the exact examples I gave but I like this one.)

    anyway, nobody liked it back then and I don't expect anyone to
    like it now.

    but since we're talking about __close and toclose and stuff, why
    not use
    __unset instead? it's called when a variable is unset i.e. goes
    out of
    scope. (as long as we don't get the ability to unset variables like I
    proposed with non-linear lexical scoping, at least.)

    it still doesn't solve the "what to name the <toclose>" problem, but,
    I'd prefer __unset over __close, personally. (ideally we'd also
    have a
    __set for when the value is assigned to one of those special
    variables,
    but I digress.)