On Sat, Jan 03, 2009 at 05:51:50PM +0100, demerphq wrote: > 2009/1/3 Matt Kraai <kraai@xxxxxxxxx>: > > I don't think Perl has *a* false value, but rather has multiple values > > that are treated as false, such as undef, zero, and the empty string. > > Personally, I find 0 clearer than the empty string, but that's > > probably just my C bias sneaking in. > > Yes it definitely does have a false value, PL_sv_no, and a true value, > PL_sv_yes (although it is much less important). It is these values > which are copied to signify true and false in the cases where the > internals need to, such as for boolean operators that must return > false, and things like negation and (in)equality checks. > > It is a so called "dual var" SvPVNV, with 0 in the NV (numeric) slot > and the empty string in the PV (string) slot. > > You can see one example of its behaviour in my previous mail, and can > see it further here: > > $ perl -MDevel::Peek -e'print Dump(shift @ARGV eq "true")' > SV = PVNV(0x952eb10) at 0x952b6f0 > REFCNT = 2147483647 > FLAGS = (IOK,NOK,POK,READONLY,pIOK,pNOK,pPOK) > IV = 0 > NV = 0 > PV = 0x952eae8 ""\0 > CUR = 0 > LEN = 4 > > Compare that to: > > perl -MDevel::Peek -e'print Dump(shift @ARGV eq "true" ? 1 : 0)' > SV = IV(0x94d8398) at 0x94bd678 > REFCNT = 1 > FLAGS = (PADBUSY,PADTMP,IOK,READONLY,pIOK) > IV = 0 Wow, I had no idea about this. Thanks for the information. It seems like using these values would require obfuscating the code, though. :( They only seem to be exposed directly via XS. -- Matt http://ftbfs.org/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
