Skip Menu |
 
rt.cpan.org will be shut down on March 1st, 2021.

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Readonly CPAN distribution.

Report information
The Basics
Id: 29487
Status: resolved
Priority: 0/
Queue: Readonly

People
Owner: sanko [...] cpan.org
Requestors: makk384 [...] gmail.com
Cc:
AdminCc:

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



Subject: inconsistent behaviour for bitmask scalars, between perl versions
Date: Wed, 19 Sep 2007 10:33:29 +0100
To: bug-Readonly [...] rt.cpan.org
From: "Mark Morgan" <makk384 [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
Good day, I've run into the following bug with Readonly; on some perl 5.8.5 systems that I'm using, the following code produces unexpected behaviour (pared down to the minimum amount of code that causes the issue): ==== #!/usr/bin/perl -l use strict; use warnings; use Readonly; Readonly my $t => 2 ** 3; Readonly my $u => 2 ** 4; print $t | $u; print $t | $u ==== Under perl 5.8.8, I get the expected result from the above of: 24 24 However, under perl 5.8.5, I get the following returned: 96 24 The first invocation is always returning the same invalid value, after which all subsequent invocation return the expected value. Both of the above were run under the same hardware and OS (linux 2.6.19-1.2911.fc6, i386). The only differences is that the top result was run under perl 5.8.8, whereas the second was on the same box running under a chroot environment, and using perl 5.8.5. I've been able to duplicate this behaviour on other 5.8.5 boxes (linux 2.6.9-55.EL, x86_64). Mark. PS: I've also running the above on a freebsd box (FreeBSD 4.8-RELEASE #0 on i386), and this is experiencing the exact same erroneous behaviour as above.
Download (untitled) / with headers
text/plain 337b
On Sep 19 05:34:06 2007, MMORGAN wrote: Show quoted text
> Good day, > > I've run into the following bug with Readonly; on some perl 5.8.5 > systems that I'm using, the following code produces unexpected > behaviour (pared down to the minimum amount of code that causes the > issue):
Is Readonly::XS installed? -- Alexandr Ciornii, http://chorny.net
Download (untitled) / with headers
text/plain 1.7k
On Wed Sep 19 05:34:06 2007, MMORGAN wrote: Show quoted text
> Good day, > > I've run into the following bug with Readonly; on some perl 5.8.5 > systems that I'm using, the following code produces unexpected > behaviour (pared down to the minimum amount of code that causes the > issue): > > ==== > #!/usr/bin/perl -l > > use strict; > use warnings; > > use Readonly; > > Readonly my $t => 2 ** 3; > Readonly my $u => 2 ** 4; > > print $t | $u; > print $t | $u > ==== > > Under perl 5.8.8, I get the expected result from the above of: > > 24 > 24 > > However, under perl 5.8.5, I get the following returned: > > 96 > 24 > > The first invocation is always returning the same invalid value, after > which all subsequent invocation return the expected value. > > Both of the above were run under the same hardware and OS (linux > 2.6.19-1.2911.fc6, i386). The only differences is that the top result > was run under perl 5.8.8, whereas the second was on the same box > running under a chroot environment, and using perl 5.8.5. > > I've been able to duplicate this behaviour on other 5.8.5 boxes (linux > 2.6.9-55.EL, x86_64). > > Mark. > > PS: I've also running the above on a freebsd box (FreeBSD 4.8-RELEASE > #0 on i386), and this is experiencing the exact same erroneous > behaviour as above.
The behavior you describe (1st access returns incorrect value) sounds like yet another magical variable bug. I cannot replicate this specific issue with the example you provided (likely fixed upstream since v5.8.x) but a similar problem still existed in v5.18.x and had to be reported to p5p as RT#120102 so I do have an idea about where the problem is/was/went. I'm marking this as resolved for now for the above reasons. :) -- Sanko Robinson sanko@cpan.org


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.