Andrew Dunstan wrote:
> Tom Lane wrote:
>
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>
>>> My take: we should document this better, but it ain't broke so it
>>> don't need fixing,
>>>
>> Actually, my take on your analysis is that there should be a way to get
>> at "use warnings" (I assume that's disallowed in trusted plperl).
>
> Yes, we can't allow "use" in trusted code. But we could turn it on in
> plperl.c, just as we can turn on strict mode, and HEAD already has the
> infrastructure for logging lexical warnings - that's a new feature. I
> will investigate turning the switch.
>
I spoke a bit rashly here. The only way I have been able to make it work
so far in the Safe container is via the global -w flag - everything else
I tried failed, although it worked just fine for untrusted code. I don't
have lots of time to spend working out why. Another issue is that the
warnings pragma is fairly recent, and so might break on older perls
anyway, so just using -w might be the best way to go, if we do anything.
However, this turns on all warnings (e.g. use of uninitialized
variables) and the user can't turn them off. Still, that might not be a
bad thing. It will just cause the warnings to be logged, although
possibly a little verbosely.
That change at least is trivial.
So what's the consensus? "-w" or just document?
FYI, here is the perldiag man page extract covering the problem:
Variable "%s" will not stay shared
(W closure) An inner (nested) named subroutine is referencing a
lexical variable defined in an outer subroutine.
When the inner subroutine is called, it will probably see the value
of the outer subroutine’s variable as it was before and during the
*first* call to the outer subroutine; in this case, after the first
call to the outer subroutine is complete, the inner and outer sub-
routines will no longer share a common value for the variable. In
other words, the variable will no longer be shared.
Furthermore, if the outer subroutine is anonymous and references a
lexical variable outside itself, then the outer and inner subrou-
tines will never share the given variable.
This problem can usually be solved by making the inner subroutine
anonymous, using the "sub {}" syntax. When inner anonymous subs
that reference variables in outer subroutines are called or refer-
enced, they are automatically rebound to the current values of such
variables.
cheers
andrew
