1 and 0 are special-cased because of their special uses:
1 while unlink($file); #used on VMS
if(0) {dont_run_this}
Since they issue a lot of false positives, they're specially ignored. Other things, however, are more often mistakes, so they're warned about.
=cut
--Brent Dax
There is no sig. | [reply]
[d/l] |
And to explore the converse, the "2t" and "3t" lines
spit out warnings instead:
#!/usr/bin/perl -w
print "1t\n" unless 1;
print "1f\n" unless 0;
print "2t\n" unless 'moo';
print "2f\n" unless '';
print "3t\n" unless '1';
print "3f\n" unless '0';
Just thought i would point this out as well ... i don't
have an answer.
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply]
[d/l] |
That is because those two lines are not doing anything. There is nothing to check since the if comparison is undefined. | [reply] |
There is nothing undefined about the comparison. The comparison evaluates to false. Perl will usually optimize out the entire statement from the parse tree when this happens to a constant test, as is the case with the "1f" line. What is interesting in this case is that perl leaves a remnant behind in the parse tree/bytecode (as Deparse seemingly indicates), presumably the constant which is being tested. This is consistent with the output of the following code:
| | | #!/usr/bin/perl -w
0;
1;
'0';
|
I believe this warning is a (very minor) bug, since the print+comparison statement should be optimized out of the parse tree entirely.
MeowChow
s aamecha.s a..a\u$&owag.print | [reply]
[d/l] |
I am not sure it is a bug.
Does this not fall under the "if it looks like a function..." rule?
Nothing was getting stored anywhere so Perl discarded it.
If you were to change to
my $a = '0';
print "3f\n" if $a;
You don't get output. But you don't get the error. | [reply]
[d/l] |
