bug report

[p5pRT]

Migrated from rt.perl.org#3161 (status was 'resolved')

Searchable as RT3161$

[p5pRT]

From lr@hpllr1.hpl.hp.com

Created by lr@hpl.hp.com

When a scalar that has a numerical value is assigned a constructed string that evaluates to a numerical value\, the previous numerical value is sometimes not invalidated.

e​:\> perl -e "my $x = 10; $x = '2' . $x; print $x + 0" 10

Any simple calculation that produces a wrong value quietly is potentially a serious problem and should be addressed. I called its severity 'medium' because Perl has survived this far without exploding any nuclear reactors. :-)

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl v5.6.0: Summary of my perl5 (revision 5 version 6 subversion 0) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=undef use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cl', optimize='-O1 -MD -DNDEBUG', gccversion= cppflags='-DWIN32' ccflags ='-O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -release -libpath:"C:\Perl\lib\CORE" -machine:x86' libpth="C:\Perl\lib\CORE" libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -libpath:"C:\Perl\lib\CORE" -machine:x86' Locally applied patches: ACTIVEPERL_LOCAL_PATCHES_ENTRY @INC for perl v5.6.0: C:/Perl/lib C:/Perl/site/lib . Environment for perl v5.6.0: HOME=C:\ LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\WINDOWS;c:\windows;c:\windows\COMMAND;C:\PERL\BIN\;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\MKSNT;C:\VIM\VIM55 PERL_BADLANG (unset) SHELL=C:\command.com ```

[p5pRT]

From @simoncozens

When a scalar that has a numerical value is assigned a constructed string that evaluates to a numerical value\, the previous numerical value is sometimes not invalidated.

Okay\, this sucks.

e​:\> perl -e "my $x = 10; $x = '2' . $x; print $x + 0" 10

Here's what's happening​: When Perl does a concatentation or substr\, it uses sv_insert to put string into another. However\, sv_insert fails to invalidate the IVness of the SV. It should do this once it's converted the SV into a PV\, since the SV is about to change. Here's the OLF​:

Inline Patch

```diff --- ../sv.c Mon Mar 13 19:18:29 2000 +++ ./sv.c Wed Apr 26 14:51:48 2000 @@ -3451,6 +3451,7 @@ if (!bigstr) Perl_croak(aTHX_ "Can't modify non-existent substring"); SvPV_force(bigstr, curlen); + SvIOK_off(bigstr); if (offset + len > curlen) { SvGROW(bigstr, offset+len+1); Zero(SvPVX(bigstr)+curlen, offset+len-curlen, char); ```

I called its severity 'medium' because Perl has survived this far without exploding any nuclear reactors. :-)

It's certainly a core problem though...

Simon __END__

---

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review\, retransmission\, dissemination or other use of\, or taking of any action in reliance upon\, this information by persons or entities other than the intended recipient is prohibited. If you received this in error\, please contact the sender and delete the material from any computer.

[p5pRT]

From @simoncozens

I stumbled​:

Inline Patch

```diff --- ../sv.c Mon Mar 13 19:18:29 2000 +++ ./sv.c Wed Apr 26 14:51:48 2000 @@ -3451,6 +3451,7 @@ if (!bigstr) Perl_croak(aTHX_ "Can't modify non-existent substring"); SvPV_force(bigstr, curlen); + SvIOK_off(bigstr); if (offset + len > curlen) { SvGROW(bigstr, offset+len+1); Zero(SvPVX(bigstr)+curlen, offset+len-curlen, char); ```

Boy, oh, boy. Better make that SvPVOK_only(bigstr); since floating-point numbers exist.

Simon __END__

---

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review\, retransmission\, dissemination or other use of\, or taking of any action in reliance upon\, this information by persons or entities other than the intended recipient is prohibited. If you received this in error\, please contact the sender and delete the material from any computer.

[p5pRT]

From [Unknown Contact. See original ticket]

Larry Rosler \lr@​hpllr1\.hpl\.hp\.com wrote

e​:\> perl -e "my $x = 10; $x = '2' . $x; print $x + 0" 10

Any simple calculation that produces a wrong value quietly is potentially a serious problem and should be addressed. I called its severity 'medium' because Perl has survived this far without exploding any nuclear reactors. :-)

The real reason no nuclear reactors have exploded is that this bug doesn't happen in 5.005_03\, and 5.6.0 hasn't been around very long.

So it's a good thing Simon has provided a patch.

Mike Guy

[p5pRT]

From [Unknown Contact. See original ticket]

M.J.T. Guy (lists.p5p)​:

The real reason no nuclear reactors have exploded is that this bug doesn't happen in 5.005_03

It doesn't happen in globals either; only lexicals. I don't know why that is.

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Apr 26\, 2000 at 03​:42​:20PM +0000\, simon@​brecon.co.uk wrote​:

M.J.T. Guy (lists.p5p)​:

The real reason no nuclear reactors have exploded is that this bug doesn't happen in 5.005_03

It doesn't happen in globals either; only lexicals. I don't know why that is.

Gosh\, does that mean that perl scripts written for nuclear reactors don't use lexical variables?

[p5pRT]

From @iabyn

fixed in 5.6.1

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'