On Tue, Dec 14, 2004 at 08:15:29AM +0000, Sisyphus wrote:
I reckon I'll understand this better when (if ever) I understand how overload.pm creates the PL_sv_yes (or PL_sv_no, as the case may be) and sends it to the overload subroutine as the third argument.
I think that you can do them in perl space as the result of boolean operations. For example:
$ perl -MDevel::Peek -e '$a=\(1==1); Dump $a' SV = RV(0x811438) at 0x808c3c REFCNT = 1 FLAGS = (ROK) RV = 0xf6ab0 SV = PVNV(0x800e30) at 0xf6ab0 REFCNT = -2147483648 FLAGS = (IOK,NOK,POK,READONLY,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x3001b0 "1"\0 CUR = 1 LEN = 2
I seem to be able to get a reference to PL_sv_yes into $a, and I believe that you can check the reference addresses with == to see if you have the real thing:
$ perl -le '$yes=\(1==1); $a=\(!!1); $t = 1 == 1; $b = \$t; foreach (qw(a b)) {print "$_: $$_: ", $$_ == $yes ? "PL_sv_yes" : "not"}' a: SCALAR(0xf6ab0): PL_sv_yes
b: SCALAR(0x808c90): not
Yes, I've got some code here that I wrote that Dump()'s things like ${\(1==1)}, ${\(0==1)} and ${\(pop())} .
Hadn't occurred to me to check the reference addresses as given by 'SCALAR(0xf6ab0)', etc.
So $a is a reference to PL_sv_yes, and $b is merely a reference to something truthful.
I think that that negative reference count on PL_sv_yes may be a bug.
Perhaps a bug in Devel::Peek ? SvREFCNT() returns an unsigned value - looks as though Devel::Peek is treating it as a signed value - which means that when the refcount of 2147483647 gets incremented by one, Devel::Peek reports it to be -2147483648 - and if it gets incremented by one again, it becomes -2147483647, etc.
Or .... do you mean that it's a bug that the reference count on PL_sv_yes gets altered at all ?
Cheers, Rob
