in reply to no warnings 'uninitialized' (was:Time to seconds)
in thread Time to seconds

Why should this cause a warning? The behavior is well-defined, documented, rational, and well understood. I don't think perl should be warning me about this since it is a feature of Perl!

Because using undef in a math operation is generally a Weird Thing, and by turning on warnings you've asked Perl to warn you about Weird Things.

If the first one gives me a "Use of uninitialized value in multiplication" error, why wouldn't this give me a "Use of uninitialized value in logical OR" error?

The reason is that logical or is often used as a defaulting operator. That idiom--$foo||$default--is so common that it's getting its own syntax in Perl 6--the new // defaulting operator, which only returns the right operand if the left operand is undefined. With this addition to Perl 6 perhaps the warning you mention will appear.

PS Sorry if this has the tone of lashing out angrily at you or something. It's probably too late for me to be safely posting to the Monastery anyway... :^)

=cut
--Brent Dax
There is no sig.

Replies are listed 'Best First'.
Re: Re: no warnings 'uninitialized' (was:Time to seconds)
by blakem (Monsignor) on Nov 16, 2001 at 16:25 UTC
    It's not weird its perlish.TM ;-)
    But seriously, using "uninitialized" variables is done all the time in perl. The weird part is trying to figure out when doing so will trigger a warning and when it won't. I'll be very impressed if you can tell what warnings the following code will produce:
    #!/usr/bin/perl -T
use warnings;
use strict;

my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m);

$a++;
$b += 1;
$c = $c + 1;

$d->{size} = 'big';
$e->[5] = 35;

$_ .= "$f";
$_ .= $g;
$_ = 'h=' . $h;
$_ = $i . '=i';
$_ = "j=$j";
$_ = "$k=k";

$_ = $l x 5;
$_ = "$m" x 5;

    [download]

    ANS: $c,$f,$g,$h,$j, and $m are used it ways that trigger warnings
 
$a++;          # this is ok
$b += 1;       # this is ok
$c = $c + 1;   # but this is bad???

$d->{size} = 'big';   # both are just fine... treating undef as a hash
+ ref 
$e->[5] = 35;         # is ok, but treat it like a 0 and I get yelled 
+at?

$_ .= "$f";      # bad
$_ .= $g;        # still bad
$_ = 'h=' . $h;  # bad.... ok so you can't treat undef like a string
$_ = $i . '=i';  # wait, no warning, maybe you can
$_ = "j=$j";     # nope this tosses an error
$_ = "$k=k";     # but this doesn't.... huh?

$_ = $l x 5;     # neither does this
$_ = "$m" x 5;   # but if I do the stringifing myself I get yelled at

    [download]

    So, how did you do? I contend that you would have scored better on this quiz if I had asked about the values of the expressions rather than about the warnnings they may or may not trigger.

    Learning how undef behaves is easy... learning when it tosses warnings is hard. This can lead to gratuitious special-casing (i.e. if ($x && $x > 3) {$y = ($z||0) + 5)) whose sole purpose is to explicitly state that undef should be treated like, well, undef!

    -Blake

[reply]
[d/l]
[select]
      All these has their more or less intuitive explanations except for the $i and $k examples, and possibly also the $1 example. I believe you did this test on ActivePerl which is unfortunate since ActivePerl is broken. Try that on coreperl and you'll see that the $i and $k examples too will emit warnings--just as they should.
[reply]
        Ah, so here is another reason to turn off that warning... different perls complain about different things. The original answers were from a unix 5.6.1 perl, but testing it against 5.005_03 on the same machine shows that $i and $k trip warnings as you noted. (of course turning off warnings prior to 5.6.0 is a bit of a pain....)

        -Blake

[reply]

In Section Seekers of Perl Wisdom