Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jjohn (22)

jjohn
  (email not shown publicly)
http://taskboy.com/
AOL IM: taskboy3000 (Add Buddy, Send Message)
Perl hack/Linux buff/OSS junkie.

Journal of jjohn (22)

Sunday July 14, 2002
04:03 PM

A case for -w

[ #6346 ]

I confess that I don't use the '-w' flag much in Perl except when I do syntax checking like:

$ perl -wc <script>

For the most part, the only warning perl issued during runtime for my programs 'Use of uninitialized value ...', which is a pretty lame warning since Perl defines new created variables to be, er, undefined. In C, you sure as heck don't want to be counting on any uninitialed variable values. Perl does the right thing, however, and that's why we use it.

Today, I found a Perl "feature" that I nearly reported as a bug. Take a look at this code:

use strict;

bar("value");
print "end\n";

sub bar {
  for ($_[0]) {

    /[a-z]/ && do {
      print "Plunging into foo()\n";
      foo();
      print "You got me!\n";
      return 1;
    };

  }

  print "fall through\n";

  return 1;
}

sub foo {

  my $ans = '';
  print "type 'q' to quit\n";
  do{
    last if lc (substr($ans, 0, 1)) eq 'q';
    print "\nstill in loop\n";
  } while( $ans = <> );

  return;
}

Earlier today, I would have expected this program to print:

Plunging into foo()
type 'q' to quit

You got me
end

This expectation would have also gone unfulfilled, since the real output is more like:

Plunging into foo()
type 'q' to quit

still in loop

fall through
end

What's going on here? It looks like the 'last' in foo() is jumping back to the loop in bar(). In fact, this is the case and -w provides some insight:

Exiting subroutine via last at ...

Kudos to p5p for adding this warning! I suspect the problem lies with the infrequently-seen-in-Perl-but-useful-Pascal construction 'do{}while()'. Since I haven't run into this behavior before and I rarely use 'do{}while(),' I'm pointing fingers at it. Still this behavior seems a little bold to me. What do you think?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

A case for -w 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
    • For the most part, the only warning perl issued during runtime for my programs 'Use of uninitialized value ...', which is a pretty lame warning since Perl defines new created variables to be, er, undefined.

    I always use 'perl -w'. I almost always find that 'Use of unitialized value' inicates a mistake that I need to correct. Sure, if you are testing for defined(), then the code can catch this and do something intelligent, but that's not usually the case in my code.

    Most typically, the use of an unitiali

    • Maybe I don't understand what you're getting at or maybe our coding styles are radically different, but I pretty much always want to be warned that I'm using an unitialized value.

      I do 'use strict,' so don't take me for a total slacker. I haven't seen many situations in my code that the 'uninitialize' warning is helpful. With 'use strict' and a -wc check, I can catch typos at compile time. After that, I normally *depend* on values being uninitialized. For instance:

      my $tmp;
      while(<>){
         $tmp

      • But -w is smart enough that it doesn't generate "that infernal warning" with .= or += (or |=, for that matter). I think it did in some older versions of Perl.

        Can you give an example of code where the "uninitialized" warning gets in your way?
    • I use perl -w but also no warnings 'uninitialized' as I do stuff like:
      my $x = something_that_might_return_undef();
      if ($x eq 'blah') {
           # i know 'blah' ne undef
      }
      and hate:
      if ($x && $x eq 'blah') {}
      • That's a great tip. In Slash (which works on perl 5.005 and up, which doesn't have the warninngs pragma), we have a __WARN__ handler that only warns if the warning doesn't match /Use of uninitialized/ or whatever.

        Yes, it is lame, but IMO, so is the warning itself.
      • I don't get it. Seems like only half the time when I get unitialized warnings it's completely harmless. The rest of the times, something_that_might_return_undef() is returning undef and I'm not expecting it to and I end up propagating an undef down into the code, with it being a problem far from the site of the original crime.
  • Basically, as far as I know at least from the last time I looked, one has trouble if
    one tries to treat do like sub. You can't return from a do,
    or other such things (or at least I couldn't). I tend to set the
    return value of a do just by having the value as the last expression.

    As it says in perldoc, really.
    --
      ---ict / Spoon
  • do {} while isn't a loop from which you can last, etc.. The relevant part of perlsyn(1) is:

    Note also that the loop control statements described later will NOT work in this construct, because modifiers don't take loop labels.

    The standard trick solution is to double-up the curlies, creating a block from which you can exit:

    do {{
      # ...
    }} while (...);

    Uuuuugly. That's the price you pay for having trailing modifiers. In perl5 at least ...

    --Nat

    • Thanks for the tip, yet I confess that this behavior violates the design principle of least astonishment. Perhaps I'm letting my Pascal heritage show a bit too much. The other wacky behavior is that the last jumps out of foo() back into bar(). I realize that next, last and redo are different spellings for goto. Still, I was surprised. In any case, I'm happy that someone had the foresight to recognize that this behavior might startle some users and to provide a warning to clue us in.

      This is one of the dusty

      • Welcome to the surprise of dynamic scope. Loop control is dynamically scoped, not lexically. When a last is encountered at runtime, the stack is popped until a scope in a last-able state is found. If you name your block and say last NAME, similar magic occurs.

        Yes, it is surprising.

        This is a legacy from Rift Valley Perl, I believe.

        --Nat

        • Google turns up no hits whatsoever for "Rift Valley Perl". There are a number of hits with "Rift Valley" and Perl in them, but nothing obvious.

          Can someone please enlighten me what "Rift Valley Perl" is?

          • It's a metaphor. Mankind's earliest upright-walking ancestors are supposed to have originated from the Rift Valley in Africa. Hence "Rift Valley Perl" was an allusion to the primitive ur-Perl around version 1.

            Yeah, I know, Dennis Miller's show was cancelled. Get a life, Torkington :-)

            --Nat

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.