Front page | perl.perl5.porters |
Postings from May 2003
On Sun, May 11, 2003 at 11:16:35AM +0100, Nick Ing-Simmons wrote:
> Dave Mitchell <davem@fdgroup.com> writes:
> >> >Any gotchas?
>
> >> A. How deep do you search? - if expression is deep and involves lots
> >> of closures or whatever this could take a while if 1st 100,000
> >> variables are all defined.
> >
> >The search is a shallowish search of the kids of the offending op.
> >Closures etc shouldn't make a difference, as its not searching pads, its
> >searching ops. It should only check a couple of vars for a binary op.
>
> So when doing this:
>
> my $j = 10;
> $foo = sub { shift(@_) + $j };
>
> $result = (($a+$b)*($c+$d))+(($g+$h)* &$foo($i));
>
> and $i is undef - you find undef scanning the '+' op in the closure
> but don't know it is $i?
Yeah, in that particular case, the op raising the warning is the '+' in
the sub, so it will see an OP_ SHIFT and give up on that branch, then
it'll see an OP_PADSV for $j with a valid value, and give up altogether.
It's possible it might handle an OP_AELEMFAST, so { $_[0] + $j } might be
able to say 'uninitialized value $_[0]'.
But in general the rule is: if the var is close at hand and can be
identified, report it; otherwise revert to the old behaviour.
--
Any [programming] language that doesn't occasionally surprise the
novice will pay for it by continually surprising the expert.
- Larry Wall
Thread Previous
|
Thread Next