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. :-)

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

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​:

--- ../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);

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.

From @simoncozens

I stumbled​:

--- ../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);

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.

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

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.

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?

From @iabyn

fixed in 5.6.1

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