On Thu, Feb 15, 2001 at 06:00:23PM -0500, Ilya Zakharevich wrote: > On Thu, Feb 15, 2001 at 10:54:57PM +0000, Nicholas Clark wrote: > > > I checked one line of the code only - one where the segfault is > > > happening on OS/2 (this segfault might be attributed to video drivers, > > > so might be not Perl fault). This one line indicates that when NV is > > > used in the IV/Uv context, the converted value is not cached. > > > > > > This line alone makes the approach deserving rejection. > > > > I don't agree that it makes the *approach* deserving of rejection. > > The implementation, yes. (in that the implementation needs to be perfect) > > It was not intended never to cache the NV value if the NV value was > > calculated from the string. > > perl5.6.0 -MDevel::Peek -wle '$a = shift; $b = $a+1; Dump $a' 12 > Name "main::b" used only once: possible typo at -e line 1. > SV = PVNV(0x11aea8) at 0x13ea38 > REFCNT = 1 > FLAGS = (NOK,POK,pNOK,pPOK) > IV = 0 > NV = 12 > PV = 0x1190a8 "12"\0 > CUR = 2 > LEN = 3 > > Enough said. You give no context. I assume you mean me to compare this with perl5.7.0 -MDevel::Peek -e '$a = shift; $b = $a + 1; Dump ($a)' 12 SV = PVIV(0x20d9380) at 0x20e3160 REFCNT = 1 FLAGS = (IOK,POK,pIOK,pPOK) IV = 12 PV = 0x20e2e38 "12"\0 CUR = 2 LEN = 3 and you are implying by "Enough said" that it is madness for there to be no NV in that SV? If so, I don't agree: pp_add is presented with 2 operands, the PV "12" and the number 1. perl5.6.0 -MDevel::Peek -e 'Dump (1)' SV = IV(0x20d20d8) at 0x20c81c0 REFCNT = 1 FLAGS = (IOK,READONLY,pIOK,IsUV) UV = 1 constant folding under 5.6.0 makes it a UV. It happens to be an IV under bleadperl, but it makes no difference if it is IV or UV, it's still stored as an integer. pp_add is presented with two SVs, neither of which is an NV. Why should it even *perform* the conversion of "12" to NV when it can convert direct to IV, and determine from the string that the string represents an integer in IV range? Nicholas ClarkThread Previous | Thread Next