Skip Menu |

This queue is for tickets about the Scalar-List-Utils CPAN distribution.

Report information
The Basics
Id: 4070
Status: resolved
Priority: 0/
Queue: Scalar-List-Utils

People
Owner: Nobody in particular
Requestors: schwern [...] pobox.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.13
Fixed in: (no value)



Subject: dualvar, 1<<31 and 5.6.0 on OS X.
Tests #8 and 9 of dualvar.t is failing with the stock Perl 5.6.0 on OS X. dumpvar(1<<31,..) is coming out as -2147483648 in numeric context instead of 2147483648. Oddly enough, it works fine if you change it to 2**31. This seems to be an OS X issue, not a 5.6.0 issue, as it dualvar(1<<31,...) works fine with 5.6.0 on Linux/x86. It also works fine with 5.8.0 on OS X built from source. It seems 1<<31 and 2**31 produce subtly different scalars. This information may prove useful: $ perl5.6.0 -wle 'print 1<<31; print 2**31' 2147483648 2147483648 $ perl5.8.0 -wle 'print 1<<31+0; print 2**31' 2147483648 2147483648 $ perl5.6.0 -MDevel::Peek -wle 'print Dump 1<<31; print Dump 2**31' SV = IV(0x10278) at 0x14748 REFCNT = 1 FLAGS = (IOK,READONLY,pIOK,IsUV) UV = 2147483648 SV = PVNV(0x7338) at 0x6650 REFCNT = 1 FLAGS = (NOK,READONLY,pNOK) IV = -2147483648 NV = 2147483648 PV = 0 $ perl5.8.0 -MDevel::Peek -wle 'print Dump 1<<31; print Dump 2**31' SV = IV(0x1389c) at 0x11948 REFCNT = 1 FLAGS = (IOK,READONLY,pIOK) IV = 2147483648 SV = PVNV(0x2b6e8) at 0x768c REFCNT = 1 FLAGS = (IOK,NOK,READONLY,pIOK,pNOK) IV = 2147483648 NV = 2147483648 PV = 0
From: Graham Barr <gbarr [...] pobox.com>
Subject: Re: [cpan #4070] dualvar, 1<<31 and 5.6.0 on OS X.
Date: Sat, 11 Oct 2003 08:30:30 +0100
To: bug-Scalar-List-Utils [...] rt.cpan.org
RT-Send-Cc:
This is a known 5.6.0 issue and there is a comment in the README that says KNOWN BUGS There is a bug in perl5.6.0 with UV's that are >= 1<<31. This will show up as tests 8 and 9 of dualvar.t failing Graham. On 11 Oct 2003, at 3:58, Guest via RT wrote: Show quoted text
> Tests #8 and 9 of dualvar.t is failing with the stock Perl 5.6.0 on OS > X. dumpvar(1<<31,..) is coming out as -2147483648 in numeric context > instead of 2147483648. Oddly enough, it works fine if you change it > to 2**31. > > This seems to be an OS X issue, not a 5.6.0 issue, as it > dualvar(1<<31,...) works fine with 5.6.0 on Linux/x86. It also works > fine with 5.8.0 on OS X built from source. > > It seems 1<<31 and 2**31 produce subtly different scalars. This > information may prove useful: > > $ perl5.6.0 -wle 'print 1<<31; print 2**31' > 2147483648 > 2147483648 > > $ perl5.8.0 -wle 'print 1<<31+0; print 2**31' > 2147483648 > 2147483648 > > $ perl5.6.0 -MDevel::Peek -wle 'print Dump 1<<31; print Dump 2**31' > SV = IV(0x10278) at 0x14748 > REFCNT = 1 > FLAGS = (IOK,READONLY,pIOK,IsUV) > UV = 2147483648 > > SV = PVNV(0x7338) at 0x6650 > REFCNT = 1 > FLAGS = (NOK,READONLY,pNOK) > IV = -2147483648 > NV = 2147483648 > PV = 0 > > $ perl5.8.0 -MDevel::Peek -wle 'print Dump 1<<31; print Dump 2**31' > SV = IV(0x1389c) at 0x11948 > REFCNT = 1 > FLAGS = (IOK,READONLY,pIOK) > IV = 2147483648 > > SV = PVNV(0x2b6e8) at 0x768c > REFCNT = 1 > FLAGS = (IOK,NOK,READONLY,pIOK,pNOK) > IV = 2147483648 > NV = 2147483648 > PV = 0 > >
From: Graham Barr <gbarr [...] pobox.com>
Subject: Re: [Comment] Re: [cpan #4070] dualvar, 1<<31 and 5.6.0 on OS X.
Date: Sun, 12 Oct 2003 12:09:10 +0100
To: bug-Scalar-List-Utils [...] rt.cpan.org
RT-Send-Cc:
The test specifically wants to generate a UV with bit 31 set, using 2**31 is no good as it generates an NV value. The test should not be a todo, because it is highlighting a bug that exists in 5.6.0. I deliberately left it failing for that reason. Graham. On 11 Oct 2003, at 9:08, Michael G Schwern via RT wrote: Show quoted text
> This message about Scalar-List-Utils was sent to you by > schwern@pobox.com via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=4070 > > > This is a comment. It is not sent to the Requestor(s): > > On Sat, Oct 11, 2003 at 03:31:06AM -0400, Graham Barr via RT wrote:
>> KNOWN BUGS >> >> There is a bug in perl5.6.0 with UV's that are >= 1<<31. This will >> show up as tests 8 and 9 of dualvar.t failing
> > Perhaps you could use 2**31 instead? That would stop the failure and > then List::Utils would be easier to install from the CPAN shell. > > Or are you specificly testing bitshifts? If so I can whip up a patch > for you that'll make the test todo. > > > -- > Michael G Schwern schwern@pobox.com > http://www.pobox.com/~schwern/ > "How would you describe TKB? As a disk exerciser? The first > manufacturer > supplied computer virus?" > -- Carl Friedberg in > > <04716E70DA1C6046BECA1F0A26579F7B02FA7E@babbage.esb.com> > >
From: Graham Barr <gbarr [...] pobox.com>
Subject: Re: [Comment] Re: Re: [cpan #4070] dualvar, 1<<31 and 5.6.0 on OS X.
Date: Mon, 13 Oct 2003 08:35:43 +0100
To: bug-Scalar-List-Utils [...] rt.cpan.org
RT-Send-Cc:
On 13 Oct 2003, at 2:41, Michael G Schwern via RT wrote: Show quoted text
>> The test should not be a todo, because it is highlighting a bug that >> exists in 5.6.0. I deliberately left it failing for that reason.
> > But there's nothing one can do about it except upgrade perl (something > that's > somewhat difficult for OS X users). Since there's nothing you can do > about > it its just an annoyance and makes List::Utils more difficult to > install > via a CPAN shell than it needs to be.
But I dont think it is the job of a module to hide bugs in Perl itself. Show quoted text
> Also, getting folks into the habit of ignoring test failures is Bad.
I am not, I am pointing out a failure in perl 5.6.0 which hopefully will cause them to upgrade Show quoted text
> That's what TODO is for.
I disagree. TODO, IMO, is for tests that fail due to something the module has still todo. In this case there is no problem with the module Show quoted text
> I could alter the test so that its TODO only for 5.6.0, that way it > will still report a failure should a future version of Perl break. > Would > that be ok?
NO. It is a failure with 5.6.0 and it will stay reporting it that way Graham.