------_=_NextPart_001_01C28007.C953E480 Content-Type: text/plain; charset="iso-8859-1" >> J Kimball (via RT) on Tuesday, October 29, 2002 8:49 AM >> On Mon, Oct 28, 2002 at 08:18:24AM -0000, a.shankar@ti.com >> (via RT) wrote: >> >> > I wrote the following program: >> > >> > $w1=<STDIN>; >> > $w2=<STDIN>; >> > @numlist = ($w1 .. $w2); >> > print @numlist; >> > >> > [run] >> > -4 (first input) >> > 0 (second input) >> > >> > it prints nothing! >> >> I see that you are running Perl on Windows. Try printing a blank line >> before you print anything else: Im pretty sure that this is not the cause of the problem. To which Abhishek Shankar said on 29 October 2002 04:34 > The print("\n"); is not solving the problem. In fact a new > problem has comes up. Under Windows if any of the inputs is 0 the program > fails. In Unix the input -4 and 0 prints the required list of numbers. But the > inputs 0 and 4 fail to print anything. I agree that this is a bug. It appears to be because the strings '0\n' and '-4\n' are not being interpreted in numeric context in the .. operator. (Although I can't duplicate your problem with "0".."4" under unix I suspect the solution is the same, see below.) At first I thought this was due to the documented behaviour of the .. operator. In that "0\n" .. "-4\n" gets evaluated. Since neither have been used in numeric context they are treated as strings. Since they dont match the rules for string increment nor for numeric arguments the range operator returns an empty list. Unfortunatley this explanation doesn't wash: E:\Bin>perl -e "print qq{-4\n}..qq{-0\n}" -4-3-2-10 E:\Bin>perl -e "print 0+qq{-4\n}..0+qq{0\n}" -4-3-2-10 Which is more or less DWIM i think. But this sure isnt: E:\Bin>perl -e "print qq{-4\n}..qq{0\n}" E:\Bin> So, my vote is that this is a bug. (it works with ("-4\n".."-0\n") but not ("-4\n".."0\n") !!?) Oh, and stripping the "\n" out doesnt change the results. V:\perl\lib\CPAN>perl -e "print qq{-4}..qq{0}" V:\perl\lib\CPAN>perl -e "print 0+qq{-4}..0+qq{0}" -4-3-2-10 Luckily the workaround is trivial indeed. Simply coerce numeric context. @numlist = (0+$w1 .. 0+$w2); or $w1=0+<STDIN>; $w2=0+<STDIN>; HTH. Yves ps Summary of my perl5 (revision 5 version 6 subversion 1) 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 usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX', optimize='-O1 -MD -DNDEBUG', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 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:"E:\Perl\lib\CORE" -machine:x86' libpth="E:\DotNet\FrameworkSDK\Lib\" "E:\Perl\lib\CORE" libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib ol eaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.li b 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:"E:\Perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 633 Built under MSWin32 Compiled at Jun 17 2002 21:33:05 ------_=_NextPart_001_01C28007.C953E480--
![]() |
0 |
![]() |
"Orton, Yves" <yves.orton@mciworldcom.de> writes: > Content-type: text/plain ; charset = "iso-8859-1" > > >> J Kimball (via RT) on Tuesday, October 29, 2002 8:49 AM > >> On Mon, Oct 28, 2002 at 08:18:24AM -0000, a.shankar@ti.com > >> (via RT) wrote: > >> > >> > I wrote the following program: > >> > > >> > $w1=<STDIN>; > >> > $w2=<STDIN>; > >> > @numlist = ($w1 .. $w2); > >> > print @numlist; > >> > > >> > [run] > >> > -4 (first input) > >> > 0 (second input) > >> > > >> > it prints nothing! > >> > >> I see that you are running Perl on Windows. Try printing a blank line > >> before you print anything else: > > Im pretty sure that this is not the cause of the problem. > > To which Abhishek Shankar said on 29 October 2002 04:34 > > The print("\n"); is not solving the problem. In fact a new > > problem has comes up. Under Windows if any of the inputs is 0 the program > > fails. In Unix the input -4 and 0 prints the required list of numbers. But > the > > inputs 0 and 4 fail to print anything. > > I agree that this is a bug. It appears to be because the strings '0\n' and > '-4\n' are not being interpreted in numeric context in the .. operator. > (Although I can't duplicate your problem with "0".."4" under unix I suspect > the solution is the same, see below.) > > At first I thought this was due to the documented behaviour of the .. > operator. In that "0\n" .. "-4\n" gets evaluated. Since neither have been > used in numeric context they are treated as strings. Since they dont match > the rules for string increment nor for numeric arguments the range operator > returns an empty list. Unfortunatley this explanation doesn't wash: > > E:\Bin>perl -e "print qq{-4\n}..qq{-0\n}" > -4-3-2-10 > E:\Bin>perl -e "print 0+qq{-4\n}..0+qq{0\n}" > -4-3-2-10 > > Which is more or less DWIM i think. But this sure isnt: > > E:\Bin>perl -e "print qq{-4\n}..qq{0\n}" > > E:\Bin> > > So, my vote is that this is a bug. (it works with ("-4\n".."-0\n") but not > ("-4\n".."0\n") !!?) Oh, and stripping the "\n" out doesnt change the > results. > > V:\perl\lib\CPAN>perl -e "print qq{-4}..qq{0}" > > V:\perl\lib\CPAN>perl -e "print 0+qq{-4}..0+qq{0}" > -4-3-2-10 > > Luckily the workaround is trivial indeed. Simply coerce numeric context. > > @numlist = (0+$w1 .. 0+$w2); > > or > > $w1=0+<STDIN>; > $w2=0+<STDIN>; > > HTH. > There is a special handling for numeric strings beginning with a "0". This is to allow things like "01".."31" to preserve the leading zero for one-digit numbers. The special handling is triggered if either the left or right operand starts with "0". For left operands this is OK but I cannot think of a useful case where only a right operand with leading zero triggers this handling. OK: $ perl -e 'print join(",", "01" .. "02"), "\n"' 01,02 Strange: $ perl -e 'print join(",", "1" .. "02"), "\n"' 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99 With the patch below, Yves' new test cases pass (and all other tests) and the output from the example below looks better: $ ./perl -e 'print join(",", "1" .. "02"), "\n"' 1,2 Regards, Slaven --- /usr/local/src/bleedperl/pp_ctl.c Tue Oct 22 20:14:24 2002 +++ ./pp_ctl.c Wed Oct 30 15:45:46 2002 @@ -946,7 +946,7 @@ PP(pp_flop) if (SvNIOKp(left) || !SvPOKp(left) || SvNIOKp(right) || !SvPOKp(right) || (looks_like_number(left) && *SvPVX(left) != '0' && - looks_like_number(right) && *SvPVX(right) != '0')) + looks_like_number(right))) { if (SvNV(left) < IV_MIN || SvNV(right) > IV_MAX) DIE(aTHX_ "Range iterator outside integer range"); -- Slaven Rezic - slaven.rezic@berlin.de tknotes - A knotes clone, written in Perl/Tk. http://ptktools.sourceforge.net/#tknotes
![]() |
0 |
![]() |