http://www.perlmonks.org?node_id=886154


in reply to how ! operator works

An empty string qualifies as "false" too. perlop tells us that ! provides logical negation, which is different from 'numeric.'

perlsyn tells us the following:

The number 0, the strings '0' and '' , the empty list () , and undef are all false in a boolean context. All other values are true. Negation of a true value by ! or not returns a special false value. When evaluated as a string it is treated as '' , but as a number, it is treated as 0.


Dave

Replies are listed 'Best First'.
Re^2: how ! operator works
by moritz (Cardinal) on Feb 04, 2011 at 08:51 UTC

    This "False" value is basically the same as

    use Scalar::Util qw/dualvar/; dualvar(0, '');

    Which stems from the curious fact that a Perl scalar internally has a slot for both a numeric and a string value. By explicitly providing a numeric value, you don't get a warning when used as a number:

    $ perl -wE 'say 1 + ""' Argument "" isn't numeric in addition (+) at -e line 1. 1 $ perl -MScalar::Util=dualvar -wE 'say dualvar(0, "") + 1' 1

    Note that when abused, these dualvars can be very confusing:

    $ perl -MScalar::Util=dualvar -E 'my $x = dualvar(42, "23"); say $x; s +ay $x + 1' 23 43

    Devel::Peek shows that the False value is a wee bit more special than that:

    perl -MDevel::Peek -MScalar::Util=dualvar -e 'Dump !1; Dump dualvar(0, + "")' SV = PVNV(0x254ff70) at 0x7409c0 REFCNT = 2147483647 FLAGS = (IOK,NOK,POK,READONLY,pIOK,pNOK,pPOK) IV = 0 NV = 0 PV = 0x254ff50 ""\0 CUR = 0 LEN = 8 SV = PVNV(0x2550d90) at 0x2551220 REFCNT = 1 FLAGS = (TEMP,IOK,POK,pIOK,pPOK) IV = 0 NV = 0 PV = 0x255f610 ""\0 CUR = 0 LEN = 8

    So it's not only a dualvar, but it's also readonly, and has a very high refcount - it's basically a singleton.

      That refcount (2147483647) looks strangely familiar. Is that a coincidence or just a hack in the interpreter so it (the object in question) never gets destroyed by the garbage collector (theoretically)?
        That refcount (2147483647) looks strangely familiar.
        Just print it out in hex and you'll see:
        7FFFFFFF
        which is a clear indication that this is the largest positive integer you can stuff into a signed 32 bit integer (2's complement).

        So yeah, your guess is very likely correct.

        So I looked at the code to answer your question. It looks like it's a hack, not a magical value. The refcount can go down, but it gets reset back to the max for SvIMMORTAL variables (the true, the false, the undef and a special internal thing called "placeholder").

      ...what'd you just call me?