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 WallThread Previous | Thread Next