FAQ
This is a bug report for perl from gbarr@monty.mutatus.co.uk,
generated with the help of perlbug 1.33 running under perl v5.7.1.


-----------------------------------------------------------------
[Please enter your report here]

The following script shows a bug that magic is not being removed from $_
at the exit of bnorm(). This only happens if the s/// matches and the
replacement contains a $1..$n variable

use Devel::Peek;

sub bnorm { #(num_str) return num_str
local($_) = @_;
s/(\d)/$1/;
}

sub doit {
print "-"x30,"\n";
my $num = (1<<17) * (1<<17);
print "$num\n";
{
local $_ = $num;
print "$_\n";
}
}

doit();
Devel::Peek::Dump($_);
bnorm("1092509802939879587398450394850984098031948509");
Devel::Peek::Dump($_);
doit();


Sample output


------------------------------
17179869184
17179869184
SV = NULL(0x0) at 0x8157108
REFCNT = 1
FLAGS = ()
SV = PVMG(0x817f140) at 0x8157108
REFCNT = 1
FLAGS = (SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x8181620
MG_VIRTUAL = &PL_vtbl_mglob
MG_TYPE = 'g'
MG_LEN = -1
------------------------------
17179869184
4294967295


this bug arises in Math::BigInt if a M:BI is compare to a normal scalar that
contains a value which is too big for an IV, eg

use Math::BigInt;
my $num = (1<<17) * (1<<17);
my $bi = Math::BigInt->new("$num");
die unless $bi == ((1<<17) * (1<<17));


[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.7.1:

Configured by gbarr at Tue Apr 10 06:55:54 BST 2001.

Summary of my perl5 (revision 5.0 version 7 subversion 1) configuration:
Platform:
osname=freebsd, osvers=4.2-release, archname=i386-freebsd
uname='freebsd monty.mutatus.co.uk 4.2-release freebsd 4.2-release #4: mon apr 9 12:01:50 bst 2001 root@monty.mutatus.co.uk:usrsrcsyscompilemutatus i386 '
config_args='-d -e -r -D cc=gcc -D optimize=-O2 -g -D prefix=/opt/perl-5.7.1 -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='gcc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include',
optimize='-O2 -g',
cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.2 19991024 (release)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lbind -lgdbm -ldb -lm -lc -lcrypt -liconv -lutil
perllibs=-lbind -lm -lc -lcrypt -liconv -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:


---
@INC for perl v5.7.1:
/opt/perl-5.7.1/lib/5.7.1/i386-freebsd
/opt/perl-5.7.1/lib/5.7.1
/opt/perl-5.7.1/lib/site_perl/5.7.1/i386-freebsd
/opt/perl-5.7.1/lib/site_perl/5.7.1
/opt/perl-5.7.1/lib/site_perl
.

---
Environment for perl v5.7.1:
HOME=/home/gbarr
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/krb5/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/gbarr/bin
PERL_BADLANG (unset)
SHELL=/usr/local/bin/zsh

Search Discussions

  • John Peacock at Apr 29, 2001 at 12:27 am

    Graham Barr wrote:

    This is a bug report for perl from gbarr@monty.mutatus.co.uk,
    generated with the help of perlbug 1.33 running under perl v5.7.1.

    -----------------------------------------------------------------
    [Please enter your report here]

    The following script shows a bug that magic is not being removed from $_
    at the exit of bnorm(). This only happens if the s/// matches and the
    replacement contains a $1..$n variable

    use Devel::Peek;

    sub bnorm { #(num_str) return num_str
    local($_) = @_;
    s/(\d)/$1/;
    }

    sub doit {
    print "-"x30,"\n";
    my $num = (1<<17) * (1<<17);
    print "$num\n";
    {
    local $_ = $num;
    print "$_\n";
    }
    }

    doit();
    Devel::Peek::Dump($_);
    bnorm("1092509802939879587398450394850984098031948509");
    Devel::Peek::Dump($_);
    doit();

    Sample output

    ------------------------------
    17179869184
    17179869184
    SV = NULL(0x0) at 0x8157108
    REFCNT = 1
    FLAGS = ()
    SV = PVMG(0x817f140) at 0x8157108
    REFCNT = 1
    FLAGS = (SMG)
    IV = 0
    NV = 0
    PV = 0
    MAGIC = 0x8181620
    MG_VIRTUAL = &PL_vtbl_mglob
    MG_TYPE = 'g'
    MG_LEN = -1
    ------------------------------
    17179869184
    4294967295
    I have been banging on this bug since Graham posted it, with
    little success (since I don't know where to start looking in
    the source).

    However, as an additional data point, I ran the same code under
    5.6.1 and got this for output:

    ------------------------------
    17179869184
    17179869184
    SV = NULL(0x0) at 0x80f8a20
    REFCNT = 1
    FLAGS = ()
    SV = PVMG(0x8129db0) at 0x80f8a20
    REFCNT = 1
    FLAGS = (SMG)
    IV = 0
    NV = 0
    PV = 0
    MAGIC = 0x80ffe98
    MG_VIRTUAL = &PL_vtbl_mglob
    MG_TYPE = 'g'
    MG_LEN = -1
    ------------------------------
    17179869184
    17179869184

    which shows that the magic bits remain set under 5.6.1, so it
    may not be the magic that is to blame (completely).

    If I change doit() to be

    sub doit {
    print "-"x30,"\n";
    my $num = (1<<17) * (1<<17);
    print "$num\n";
    {
    local $_ = $num;
    Devel::Peek::Dump($_); # what is $_ now???
    print "$_\n";
    }
    }

    Then under 5.6.1 I get (for the second call to doit):

    17179869184
    SV = PVMG(0x8129d90) at 0x80f8b58
    REFCNT = 1
    FLAGS = (SMG,NOK,pNOK)
    IV = 0
    NV = 17179869184
    PV = 0
    MAGIC = 0x80ff500
    MG_VIRTUAL = &PL_vtbl_mglob
    MG_TYPE = 'g'
    MG_LEN = -1
    17179869184

    and under 5.7.1 I get (full output):

    ------------------------------
    17179869184
    SV = PVNV(0x813e708) at 0x813d86c
    REFCNT = 1
    FLAGS = (NOK,pIOK,pNOK,IsUV)
    UV = 4294967295
    NV = 17179869184
    PV = 0
    17179869184
    SV = NULL(0x0) at 0x813d818
    REFCNT = 1
    FLAGS = ()
    SV = PVMG(0x8175c68) at 0x813d818
    REFCNT = 1
    FLAGS = (SMG)
    IV = 0
    NV = 0
    PV = 0
    MAGIC = 0x8144970
    MG_VIRTUAL = &PL_vtbl_mglob
    MG_TYPE = 'g'
    MG_LEN = -1
    ------------------------------
    17179869184
    SV = PVMG(0x8175c48) at 0x813d920
    REFCNT = 1
    FLAGS = (SMG,IOK,NOK,pIOK,pNOK,IsUV)
    UV = 4294967295
    NV = 17179869184
    PV = 0
    MAGIC = 0x8144970
    MG_VIRTUAL = &PL_vtbl_mglob
    MG_TYPE = 'g'
    MG_LEN = -1
    4294967295

    where the stringification is taking the value from the UV, not
    not the NV, but only on the _second_ time through. So it appears
    that the UV must be set _and_ the magic must be set for this bug
    to appear.

    So there seems to be three questions:

    1) Should the local($_) call be stripping the magic off when
    the context is exited? It doesn't in 5.6.1, either.

    2) Should the UV be set at all when the value is too large to
    store there? I realize this may be an optimization "feature"
    but should the IOK be set if the value actually overflowed and
    was stored in the NV instead?

    3) If YES for 2) why is this magic confusing the stringification
    operator to use the UV instead of the NV? Is this because the IOK
    flag is set (erroneously)?

    If anyone can point me at the likely source files where this
    all happens, I'll keep digging.

    HTH

    John Peacock
  • Robin Houston at Apr 30, 2001 at 11:05 am

    John Peacock wrote:
    If anyone can point me at the likely source files where this
    all happens, I'll keep digging.
    I suspect the problem lies in scope.c, lines 678 ff.

    That's where localised scalars are restored on a block exit,
    and the comment /* XXX This branch is pretty bogus. */ in the
    branch that deals with magic suggests that all may not be well
    there.

    .robin.

    --
    "Do nine men interpret?" "Nine men," I nod.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedApr 26, '01 at 9:33p
activeApr 30, '01 at 11:05a
posts3
users3
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase