in reply to Warning for checking with undef

Whereas testing defined($var) is arguably better style; I feel I should point out that the use of undef shown in the responses above is wrong for the wrong reason with respect to the OP.

undef needs to be parsed as a function call in this context, so when used in the context of a relational expression, it needs round brackets after it to prevent it from being treated as a bareword. i.e. 

if ( $foo == undef() )

[download]

would work just as well as 

unless( defined($foo) )

[download]

whereas

if ( $foo == undef )

[download]

fails to satisfy for the same reason as

if ( $foo == DoesntMatterIfIamADefinedFunctionOrNot )

[download]

The same programming error is often made with shift();

One world, one people

Replies are listed 'Best First'.
Re^2: Warning for checking with undef
by Fletch (Bishop) on Jul 07, 2005 at 14:20 UTC

    Erm, undef without parens returns a perfectly valid value in that context. The problem is that it's being coerced into a numeric value because of the == which triggers the warning.

    What you're thinking of is using undef or shift as a hash key ($h{undef}) or to the left of a => (%a = ( undef => 1 )) where there is some bareword magic going on (strict or no). In those cases it is necessary to use parens or a + to disable the magic.

    Update: And you can verify it by looking at the different errors produced. Bareword-ness doesn't enter into it. 

    freebie:~ 746> cat baz
use warnings;
if( 5 == undef ) { 1 }
if( 5 == "undef" ) { 1 }
freebie:~ 747> perl baz
Argument "undef" isn't numeric in numeric eq (==) at baz line 3.
Use of uninitialized value in numeric eq (==) at baz line 2.

    [download]

    The first one gripes about comparing against undef, the second because you're comparing a non-numeric value numerically.

    --
    We're looking for people in ATL

[reply]
[d/l]
[select]
      I am testing on 5.6.1 and will have to look into it again, because my results look different from others.

      One world, one people

[reply]

        Yes it evaluates to true, because undef is zero numerically regardless of where it came from. It also triggers warnings from each side when the undefined value is coerced into a number, which is exactly what the OP was seeing. 

        freebie:~ 755> cat quux
use warnings;
my $foo = undef;
if( $foo == undef ) { print "true\n" }
freebie:~ 756> perl quux
Use of uninitialized value in numeric eq (==) at quux line 3.
Use of uninitialized value in numeric eq (==) at quux line 3.         
+          
true

        [download]

        Update: Added something that runs inside the conditional to show that it's not being interpreted as a bareword, both sides trigger the undef-used-as-a-number warning, and that the conditional is true without parens.

        --
        We're looking for people in ATL

[reply]
[d/l]
        A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom