From oleg.mihalich@gmail.com

Created by oleg.mihalich@gmail.com

This is a bug report for perl from oleg.mihalich@​gmail.com,
generated with the help of perlbug 1.36 running under perl 5.10.0.

-----------------------------------------------------------------
The following issue occurs when I use two nested foreach loops (by
'foreach loop' I mean also a for loop iterating through the return of
range operator)​:
bignum pragma does not affect the print operator inside the first pair
of nested loops, but it does in the second one.

Test case​:

use bignum;

# here we have the bug
for my $x ( 95 .. 100 ) {
  for my $y ( 1e2 .. 1e2 + 10 ) {
  print $x ** $y, "\n";
  }
}

# and here we don't
for my $x ( 95 .. 100 ) {
  for( my $y = 1e2; $y <= 1e2 + 10; $y++ ) {
  print $x ** $y, "\n";
  }
}

Flags:
     category=core
     severity=low

Site configuration information for perl 5.10.0:

Configured by root at Mon Jul  7 23:00:46 EST 2008.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
   Platform:
     osname=linux, osvers=2.6.25-arch, archname=i686-linux-thread-multi
     uname='linux arch 2.6.25-arch #1 smp preempt thu jul 3 20:29:23 
cest 2008 i686 intel(r) core(tm)2 cpu t7200 @ 2.00ghz genuineintel 
gnulinux '
     config_args='-des -Dusethreads -Doptimize=-march=i686 
-mtune=generic -O2 -pipe -Dprefix=/usr -Dinstallprefix=/usr 
-Dvendorprefix=/usr -Dprivlib=/usr/share/perl5/core_perl 
-Darchlib=/usr/lib/perl5/core_perl 
-Dsitelib=/usr/share/perl5/site_perl/5.10.0 
-Dsitearch=/usr/lib/perl5/site_perl/5.10.0 
-Dvendorlib=/usr/share/perl5/vendor_perl 
-Dvendorarch=/usr/lib/perl5/vendor_perl 
-Dotherlibdirs=/usr/lib/perl5/current:/usr/lib/perl5/site_perl/current 
-Dscriptdir=/usr/bin/perlbin/core -Dsitescript=/usr/bin/perlbin/site 
-Dvendorscript=/usr/bin/perlbin/vendor -Dman1ext=1perl -Dman3ext=3perl'
     hint=recommended, useposix=true, d_sigaction=define
     useithreads=define, usemultiplicity=define
     useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
     use64bitint=undef, use64bitall=undef, uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing 
-pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
     optimize='-march=i686 -mtune=generic -O2 -pipe',
     cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-I/usr/local/include'
     ccversion='', gccversion='4.3.1 20080626 (prerelease)', 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, prototype=define
   Linker and Libraries:
     ld='cc', ldflags =' -L/usr/local/lib'
     libpth=/usr/local/lib /lib /usr/lib
     libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
     perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
     libc=/lib/libc-2.8.so, so=so, useshrplib=false, libperl=libperl.a
     gnulibc_version='2.8'
   Dynamic Linking:
     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
     cccdlflags='-fPIC', lddlflags='-shared -march=i686 -mtune=generic 
-O2 -pipe -L/usr/local/lib'

Locally applied patches:



@INC for perl 5.10.0:
     /usr/lib/perl5/site_perl/5.10.0
     /usr/share/perl5/site_perl/5.10.0
     /usr/lib/perl5/vendor_perl
     /usr/share/perl5/vendor_perl
     /usr/share/perl5/vendor_perl
     /usr/lib/perl5/core_perl
     /usr/share/perl5/core_perl
     /usr/lib/perl5/current
     /usr/lib/perl5/site_perl/current
     .


Environment for perl 5.10.0:
     HOME=/home/olleg
     LANG=en_US.utf8
     LANGUAGE (unset)
     LC_COLLATE=C
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
     
PATH=/usr/lib/jvm/java-6-sun-1.6.0.03/jre/bin:/home/olleg/bin:/usr/lib/jvm/java-6-sun-1.6.0.03/jre/bin:/bin:/usr/bin:/sbin:/usr/sbin:/opt/kde/bin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core:/opt/qt/bin
     PERL_BADLANG (unset)
     SHELL=/bin/bash

From @ikegami

On Sat, Mar 7, 2009 at 7​:08 PM, via RT Oleg Komarov <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Oleg Komarov
# Please include the string​: [perl #63696]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=63696 >

This is a bug report for perl from oleg.mihalich@​gmail.com,
generated with the help of perlbug 1.36 running under perl 5.10.0.

-----------------------------------------------------------------
The following issue occurs when I use two nested foreach loops (by
'foreach loop' I mean also a for loop iterating through the return of
range operator)​:
bignum pragma does not affect the print operator inside the first pair
of nested loops, but it does in the second one.

Test case​:

use bignum;

# here we have the bug
for my $x ( 95 .. 100 ) {
for my $y ( 1e2 .. 1e2 + 10 ) {
print $x ** $y, "\n";
}
}

# and here we don't
for my $x ( 95 .. 100 ) {
for( my $y = 1e2; $y <= 1e2 + 10; $y++ ) {
print $x ** $y, "\n";
}
}

It's got nothing to do with "for". Even outside a loop, the operands of ".."
must be native integers. And since ".." can't be overriden, bignum can
loosen that restriction. If there's a bug, it's that ".." can't be
overriden.

The RT System itself - Status changed from 'new' to 'open'

*** From @ikegami

On Sat, Mar 7, 2009 at 7​:08 PM, via RT Oleg Komarov <
perlbug-followup@​perl.org> wrote​:

• New Ticket Created by Oleg Komarov
• Please include the string​: [perl *63696]
• in the subject line of all future correspondence about this issue.
• <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=63696 >
  This is a bug report for perl from oleg.mihalich@​gmail.com,
  generated with the help of perlbug 1.36 running under perl 5.10.0.

---

The following issue occurs when I use two nested foreach loops (by
'foreach loop' I mean also a for loop iterating through the return of
range operator)​:
bignum pragma does not affect the print operator inside the first pair
of nested loops, but it does in the second one.
Test case​:
use bignum;

• here we have the bug
  for my $x ( 95 .. 100 ) {
  for my $y ( 1e2 .. 1e2 + 10 ) {
  print $x ** $y, "\n";
  }
  }
• and here we don't
  for my $x ( 95 .. 100 ) {
  for( my $y = 1e2; $y <= 1e2 + 10; $y++ ) {
  print $x ** $y, "\n";
  }
  }

It's got nothing to do with "for". Even outside a loop, the operands of ".."
must be native integers. And since ".." can't be overriden, bignum can
loosen that restriction. If there's a bug, it's that ".." can't be
overriden.

No discussion since 2009. Taking for the purpose of closing.

Thank you very much.
Jim Keenan

It's got nothing to do with "for". Even outside a loop, the operands of ".."
must be native integers. And since ".." can't be overriden, bignum can
loosen that restriction. If there's a bug, it's that ".." can't be
overriden.

I meant: bignum can't loosen that restriction

*** From @ikegami
On Sat, Mar 7, 2009 at 7​:08 PM, via RT Oleg Komarov <
perlbug-followup@​perl.org> wrote​:

• New Ticket Created by Oleg Komarov
• Please include the string​: [perl *63696]
• in the subject line of all future correspondence about this issue.
• <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=63696 >
  This is a bug report for perl from oleg.mihalich@​gmail.com,
  generated with the help of perlbug 1.36 running under perl 5.10.0.

The following issue occurs when I use two nested foreach loops (by
'foreach loop' I mean also a for loop iterating through the return of
range operator)​:
bignum pragma does not affect the print operator inside the first pair
of nested loops, but it does in the second one.
Test case​:
use bignum;

• here we have the bug
  for my $x ( 95 .. 100 ) {
  for my $y ( 1e2 .. 1e2 + 10 ) {
  print $x ** $y, "\n";
  }
  }
• and here we don't
  for my $x ( 95 .. 100 ) {
  for( my $y = 1e2; $y <= 1e2 + 10; $y++ ) {
  print $x ** $y, "\n";
  }
  }

It's got nothing to do with "for". Even outside a loop, the operands of ".."
must be native integers. And since ".." can't be overriden, bignum can't
loosen that restriction. If there's a bug, it's that ".." can't be
overriden.

No discussion since 2009. Taking for the purpose of closing.

Thank you very much.
Jim Keenan

Closing as per schedule.