develooper Front page | perl.perl5.porters | Postings from February 2001

Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)

From:
Nicholas Clark
Date:
February 15, 2001 15:59
Subject:
Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)
Message ID:
20010215235927.G69568@plum.flirble.org
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 Clark




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About