Front page | perl.perl5.porters |
Postings from May 2003
On Sat, May 10, 2003 at 11:26:50PM +0100, Nick Ing-Simmons wrote: > Dave Mitchell <davem@fdgroup.com> writes: > >Currently, code like the following produces the warning shown: > > > > $ perl -wle 'my $x=1; my $y; print $x+$y' > > Use of uninitialized value in addition (+) at -e line 1. > > 1 > > > >When the code is more complicated, it becomes very irritating that > >Perl doesn't tell you the name of the variable that had the undef value. > > > >I include a proof-of-concept patch below (not to be applied !!!!) > >that produces the following warning instead: > > > > Use of uninitialized variable $y in addition (+) at -e line 1. > > > >The idea is that in the case of printing out the warning when PL_op > >is valid, the children of PL_op are recursively examined to look > >for a pad/gv-type op whose varable's value is currently undefined, and if > >so, substitute the name of the var. If it can't be found, then it reverts > >to the old behaviour. > > > >Is this a good idea, and should I pursue it into a full patch? > >(The demo patch below only works for lexicals and +/-.) > > > >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. > B. IIRC geting names of pad variables at run-time is tricky - the names > are there in compile phase. This is easy now with Perl_find_runcv(), which was added as part of a fix to allow eval to see the full lexical scope. > C. Rember to fully qualify name if it is not in current package. Will do, thanks. -- "There's something wrong with our bloody ships today, Chatfield." Admiral Beatty at the Battle of Jutland, 31st May 1916.Thread Previous | Thread Next