[31825] in Perl-Users-Digest
Perl-Users Digest, Issue: 3088 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 20 14:09:29 2010
Date: Fri, 20 Aug 2010 11:09:12 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 20 Aug 2010 Volume: 11 Number: 3088
Today's topics:
Re: ActivePerl Migration Win 2003 Server to Win 2008 Se <mvdwege@mail.com>
Re: ActivePerl Migration Win 2003 Server to Win 2008 Se <m@rtij.nl.invlalid>
Re: ActivePerl Migration Win 2003 Server to Win 2008 Se <ben@morrow.me.uk>
Re: Multiple regex operations <ben@morrow.me.uk>
Re: Perl array bug? <ben@morrow.me.uk>
Re: Perl array bug? <ben@morrow.me.uk>
Re: Perl array bug? <derykus@gmail.com>
Re: Perl array bug? (Malcolm Hoar)
Re: Perl array bug? (Malcolm Hoar)
Re: Perl array bug? <ben@morrow.me.uk>
Re: Perl array bug? <dilbert1999@gmail.com>
Re: Perl array bug? <ben@morrow.me.uk>
Re: Perl array bug? (Malcolm Hoar)
Perldoc: integers *stored* as... ??? <here@softcom.net>
Re: Perldoc: integers *stored* as... ??? <ben@morrow.me.uk>
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi <ralph@happydays.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 20 Aug 2010 16:55:33 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: ActivePerl Migration Win 2003 Server to Win 2008 Server
Message-Id: <8639u972qi.fsf@gareth.avalon.lan>
l v <veatchla@yahoo.com> writes:
> On 8/19/2010 6:01 AM, Klaus wrote:
<snip>
>> Now I have to migrate Windows Server from 2003 to 2008.
>>
>> Before I embark on this adventure, I would ask for the wisdom of the
>> perl user community:
>>
>> - Does anybody have experience with migrating perl programs from
>> Windows Server 2003 to 2008 ?
>>
>> - Are there any pitfalls I need to be aware of ?
>>
>> - Do you recommend upgrading from perl 5.10 (x64) to the newer perl
>> 5.12 (x64) at the same time ?
>
> I would keep the Perl version the same during the server migration /
> upgrade so as not to complicate the migration.
>
> I'm sure I'll catch some flak over this.
Why?
It's common sense in doing systems administration: never execute more
than one change at a time. If something goes wrong, you don't have to
first debug which change cased the problem, you can just roll back the
last change.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Fri, 20 Aug 2010 19:37:35 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: ActivePerl Migration Win 2003 Server to Win 2008 Server
Message-Id: <v3r2k7-slo.ln1@news.rtij.nl>
On Fri, 20 Aug 2010 16:55:33 +0200, Mart van de Wege wrote:
> l v <veatchla@yahoo.com> writes:
>
>> I'm sure I'll catch some flak over this.
>
> Why?
>
> It's common sense in doing systems administration: never execute more
> than one change at a time. If something goes wrong, you don't have to
> first debug which change cased the problem, you can just roll back the
> last change.
>
Not quite, it's always a risk/benefit trade off. If rollback is easy and
the risks are low, it may very well be beneficial to bother your users
only once and do all changes at once.
And as you tested all changes beforehand, the risks should be low.
(I currently work in a bank where every environment has a complete DTAP
street where this holds, and at the some other gig where you are lucky if
some test environment can be freed, all IT is outsourced and changes
normally go sour. Guess which one follows which change model...)
M4
------------------------------
Date: Fri, 20 Aug 2010 18:58:41 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ActivePerl Migration Win 2003 Server to Win 2008 Server
Message-Id: <hbs2k7-3qp1.ln1@osiris.mauzo.dyndns.org>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Fri, 20 Aug 2010 16:55:33 +0200, Mart van de Wege wrote:
> > l v <veatchla@yahoo.com> writes:
> >> I'm sure I'll catch some flak over this.
> >
> > Why?
> >
> > It's common sense in doing systems administration: never execute more
> > than one change at a time. If something goes wrong, you don't have to
> > first debug which change cased the problem, you can just roll back the
> > last change.
>
> Not quite, it's always a risk/benefit trade off. If rollback is easy and
> the risks are low, it may very well be beneficial to bother your users
> only once and do all changes at once.
Yes, of course. (I mentioned this in my followup.) The question is
whether you do your tests by upgrading both OS and perl at the same
time, or upgrade one, test thoroughly, upgrade the other, test
thoroughly, push to production. In the latter case you have a much
better chance of working out the cause of any errors that you discover.
Ben
------------------------------
Date: Fri, 20 Aug 2010 11:19:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Multiple regex operations
Message-Id: <9f12k7-0e81.ln1@osiris.mauzo.dyndns.org>
Quoth =?ISO-8859-1?Q?Orion_M=EDmamei=F0r?= <zacharyelliott1@gmail.com>:
> Is there a way to apple multiple regex operations to a single string
> without writing them all out?
>
> example.
>
> suppose I have some variable $var and want it apple three regexs to
> it. is there a faster way than
>
> $var =~ s/foo/bar/;
> $var =~ s/foo/bar/;
> $var =~ s/foo/bar/;
Use 'for'.
for ($var) {
s/foo/bar/;
s/baz/quux/;
}
Ben
------------------------------
Date: Fri, 20 Aug 2010 11:07:07 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl array bug?
Message-Id: <bn02k7-0e81.ln1@osiris.mauzo.dyndns.org>
Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
> Malcolm Hoar wrote:
> >
> > So here's the offending part of the code:
> >
> > foreach $key (@Big1) {
> > $len = length ($key);
> > if ($len) {
> > if ($key eq '') {
> > print "Here's our bad boy\n";
> > use Devel::Peek ();
> > Devel::Peek::Dump $key;
> > }
> >
> > and the output:
> >
> > Here's our bad boy
> > SV = PVLV(0x2c4488) at 0x32979a8
> > REFCNT = 2
> > FLAGS = (GMG,SMG)
> > IV = 0
> > NV = 0
> > PV = 0
> > MAGIC = 0x34932d8
> > MG_VIRTUAL = &PL_vtbl_defelem
> > MG_TYPE = PERL_MAGIC_defelem(y)
>
> This looks like the magic undef that Perl uses in sparse arrays. All
> (more or less) of the the sparce undefs point to the same structure, to
> save memory. That structures knows that, if assigned to, it has to
> mutate the thing pointing to it into a real scalar.
Not quite. Array elements that haven't ever been assigned to are not
actually allocated at all. When you evaluate one as a lvalue, the value
returned is a (newly allocated) lvalue proxy, which is a magical scalar
that points to the value it is proxying for; a 'y' type PVLV with
non-zero TARGLEN and no MG_OBJ in its 'y' magic is an array element,
with a pointer to the array it comes from in TARG and its index in
TARGOFF. If that value is assigned to, it allocates a slot in the real
array, changes TARG to point to this new slot, and sets TARGLEN to 0 to
indicate that fact. (It also has to check that the array element hasn't
been allocated already by something else, so it doesn't overwrite it.)
It's likely that a loop looking at succesive not-yet-defined array
elements will get PVLVs allocated at the same address, but that's just
the usual perl reuse-memory-if-we-can optimisation. The PVLV will have
been freed and reallocated in the meanwhile, so they're logically
distinct values.
> > Unfortunately, I don't understand any of that. If you or anyone
> > else sees any clues in there, I would be most happy to hear
> > from you!
>
> I don't understand much of it either. But your format differs from mine
> shortly after where I trimmed it, but I'm using a different version and
> different OS, so that might be expected.
I see TARGLEN as a large integer, rather than -1, but I think that's
because I've built perl with use64bitint on a 32bit machine. TARGLEN is
actually a STRLEN, but Devel::Peek casts it to IV before printing it, so
whether a large value shows up as -1 or a large integer depends on
whether STRLEN and IV are the same length or not.
Ben
------------------------------
Date: Fri, 20 Aug 2010 11:13:11 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl array bug?
Message-Id: <n212k7-0e81.ln1@osiris.mauzo.dyndns.org>
Quoth malch@malch.com (Malcolm Hoar):
> In article <4c6e2d22$0$6889$9b4e6d93@newsspool2.arcor-online.net>, Wolf
> Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> wrote:
>
> >This is Perl, not C. Undef is an empty string when converted to a
> >string, not some random garbage. It is zero when used in calculations.
> >
> >It *is* well defined!
> >
> >Read perlsyn!
> >------
> >The only things you need to declare in Perl are report formats and
> >subroutines (and sometimes not even subroutines). A variable holds the
> >undefined value ("undef") until it has been assigned a defined value,
> >which is anything other than "undef". When used as a number, "undef" is
> >treated as 0; when used as a string, it is treated as the empty string,
> >""; and when used as a reference that isn't being assigned to, it is
> >treated as an error.
> >------
>
> Ahhh, thank you. I had been searching for a more formal definition
> and explanation of the undef value and had not yet found this.
> I kept finding more and more references to the undef function
> which wasn't what I needed.
>
> This basically confirms and formalizes all of my instincts!
>
> I am very curious to know if anyone can reproduce the problem
> on a non-Windows system. If the issue is Windows specific, I
> will certainly contact ActiveState directly.
I can't reproduce here, but I haven't been trying terribly hard :).
It's going to be tough to reproduce without a testcase. If you can, it
would be good to start stripping things out of you app until you can't
reproduce the problem any more.
> It's been a while since I've formally reported a Perl bug.
> What's the preferred channel these days? perlbug, or something
> else?
perlbug is correct, but without a test case it's rather unlikely anyone
can do anything about it. (It is, of course, possible someone on p5p
will spot something I haven't.)
Ben
------------------------------
Date: Fri, 20 Aug 2010 05:07:22 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Perl array bug?
Message-Id: <db2ddd4d-f3e3-4c06-af29-105eb8149c8e@w15g2000pro.googlegroups.com>
On Aug 19, 1:15=A0pm, ma...@malch.com (Malcolm Hoar) wrote:
> In article <87y6c2s82a....@quad.sysarch.com>, "Uri Guttman" <u...@StemSys=
tems.com> wrote:
> >that was what i should have suggested. defined is a better test than
> >length as it makes more logical sense and won't be confused.
>
> >there are some subtle things with arrays and undefining entries. are you
> >doing that? i never like to see undef used like a function.
>
> No. This array name is reused a lot (which helps memory usage).
> But it's explicitly cleared at the start of the problem module:
>
> @Big1 =3D ();
Does anything change with the alternative:
undef @Big1;
This might be a quick fix or at least help
diagnose the scope of the bug...
>
> Elements are set, modified, and used but never deleted/undef'ed.
>
> Before the module returns, the array is completely cleared
> once again.
>
is there some reason for clearing again...
--
Charles DeRykus
------------------------------
Date: Fri, 20 Aug 2010 14:51:34 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Perl array bug?
Message-Id: <i4m4pm6m1t8002malch@news.sonic.net>
In article <db2ddd4d-f3e3-4c06-af29-105eb8149c8e@w15g2000pro.googlegroups.com>, "C.DeRykus" <derykus@gmail.com> wrote:
>> @Big1 =3D ();
>
>Does anything change with the alternative:
>
> undef @Big1;
No.
>> Before the module returns, the array is completely cleared
>> once again.
>
> is there some reason for clearing again...
To reduce virtual memory consumption. This is one of
many huge arrays in the "real" application. I had to
opmtimize the heck out of memory usage.
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Fri, 20 Aug 2010 14:56:18 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Perl array bug?
Message-Id: <i4m52i6m1t8004malch@news.sonic.net>
In article <n212k7-0e81.ln1@osiris.mauzo.dyndns.org>, Ben Morrow <ben@morrow.me.uk> wrote:
>It's going to be tough to reproduce without a testcase. If you can, it
>would be good to start stripping things out of you app until you can't
>reproduce the problem any more.
Yeah, I think you missed the top part of that post, with a
test case ;-)
>perlbug is correct, but without a test case it's rather unlikely anyone
>can do anything about it. (It is, of course, possible someone on p5p
>will spot something I haven't.)
Here's a draft of what I plan to submit via perlbug including
the test case:
This is a bug report for perl from malch@malch.com,
Operating System: 64-bit Windows 7.
Perl Version: ActivePerl version 5.12.1.1201 64-bit:
---
Flags:
category=core
severity=high
---
Code to reproduce this problem:
#====================================================
@Big1 = ();
$Big1[4] = 0;
$Big1[9] = 1;
$Big1[6] = 2;
my $len = 0; # This appears to be significant
foreach $key (@Big1) {
$len = length ($key);
print "key = $key, len=$len\n";
}
exit;
#=====================================================
Using ActivePerl version 5.12.1.1201 64-bit I get:
C:\ZIP>c:\perl512\bin\perl.exe test.pl
key = , len=0
key = , len=0
key = , len=0
key = , len=0
key = 0, len=1
key = , len=1 <==== ???
key = 2, len=1
key = , len=1 <==== ???
key = , len=1 <==== ???
key = 1, len=1
Using ActivePerl version 5.10.1.1007 64-bit I get:
C:\ZIP>C:\perl510\bin\perl.exe test.pl
key = , len=0
key = , len=0
key = , len=0
key = , len=0
key = 0, len=1
key = , len=0
key = 2, len=1
key = , len=0
key = , len=0
key = 1, len=1
Some other Perl programmers have taken the position that this
is a programmer error because the code attempts to establish
the length() of an undef value. That, they say, is garbage
analogous to division by zero.
I disagree and cite the following in support of my position
that this constitutes a bug:
1. Perl Version 5.10.1.1007 and every other major Perl version
going back 10 plus years have consistently returned zero
for the length of an undef value.
2. perlsyn clearly states:
"A variable holds the undefined value ("undef") until it has been
assigned a defined value, which is anything other than "undef".
When used as a number, "undef" is treated as 0; when used as a
string, it is treated as the empty string, ""; and when used as
a reference that isn't being assigned to, it is treated as an error."
Thus "undef" should be treated as the empty string. And the
length of the empty string is unambiguously zero. Hence the
behaviour of the 5.12.1.1201 is clearly a bug!
Summary of my perl5 (revision 5 version 12 subversion 1) configuration:
[snip]
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Fri, 20 Aug 2010 17:15:13 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl array bug?
Message-Id: <h9m2k7-5gb1.ln1@osiris.mauzo.dyndns.org>
Quoth malch@malch.com (Malcolm Hoar):
> In article <n212k7-0e81.ln1@osiris.mauzo.dyndns.org>, Ben Morrow
> <ben@morrow.me.uk> wrote:
>
> >It's going to be tough to reproduce without a testcase. If you can, it
> >would be good to start stripping things out of you app until you can't
> >reproduce the problem any more.
>
> Yeah, I think you missed the top part of that post, with a
> test case ;-)
Oh! Yes, I did. Thank you for taking the time to come up with this.
> Code to reproduce this problem:
>
> #====================================================
>
> @Big1 = ();
> $Big1[4] = 0;
> $Big1[9] = 1;
> $Big1[6] = 2;
> my $len = 0; # This appears to be significant
> foreach $key (@Big1) {
> $len = length ($key);
> print "key = $key, len=$len\n";
> }
> exit;
>
> #=====================================================
>
> Using ActivePerl version 5.12.1.1201 64-bit I get:
>
> C:\ZIP>c:\perl512\bin\perl.exe test.pl
> key = , len=0
> key = , len=0
> key = , len=0
> key = , len=0
> key = 0, len=1
> key = , len=1 <==== ???
> key = 2, len=1
> key = , len=1 <==== ???
> key = , len=1 <==== ???
> key = 1, len=1
I can confirm that I see the same output with
Summary of my perl5 (revision 5 version 12 subversion 1) configuration:
Platform:
osname=freebsd, osvers=8.1-release, archname=i386-freebsd-64int
[...]
Characteristics of this binary (from libperl):
Compile-time options: MYMALLOC PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
and with
Summary of my perl5 (revision 5 version 13 subversion 3) configuration:
Commit id: beeec492daca10de7e6f32d0689c6854448e5e7c
Platform:
osname=freebsd, osvers=8.1-release,
archname=i386-freebsd-thread-multi-64int
[...]
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY MYMALLOC
PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
PERL_TRACK_MEMPOOL PERL_USE_DEVEL USE_64_BIT_INT
USE_ITHREADS USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
USE_REENTRANT_API
so this is definitely a 5.12 regression and it hasn't been fixed yet.
Now we've got a clean testcase I'll have a look and see if I can see
what's going wrong, but please go ahead and report the bug anyway.
Ben
------------------------------
Date: Fri, 20 Aug 2010 09:35:19 -0700 (PDT)
From: Dilbert <dilbert1999@gmail.com>
Subject: Re: Perl array bug?
Message-Id: <17c361e1-8042-4c59-8fdf-c23cff7ee595@w30g2000yqw.googlegroups.com>
On 20 ao=FBt, 16:56, ma...@malch.com (Malcolm Hoar) wrote:
> In article <n212k7-0e81....@osiris.mauzo.dyndns.org>, Ben Morrow <b...@mo=
rrow.me.uk> wrote:
> >It's going to be tough to reproduce without a testcase. If you can, it
> >would be good to start stripping things out of you app until you can't
> >reproduce the problem any more.
>
> Code to reproduce this problem:
>
> #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>
> @Big1 =3D ();
> $Big1[4] =3D 0;
> $Big1[9] =3D 1;
> $Big1[6] =3D 2;
> my $len =3D 0; # This appears to be significant
> foreach $key (@Big1) {
> =A0 $len =3D length ($key);
> =A0 print "key =3D $key, len=3D$len\n";}
>
> exit;
>
> #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
This sounds very much like a regression in Perl 5.12.
Here is an even simpler test case:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
use Test::More tests =3D> 4;
my $my_len;
$my_len =3D length('abc');
is($my_len, 3, 'length("abc") with my variable must be 3');
$my_len =3D length(undef);
is($my_len, 0, 'length(undef) with my variable must be 0');
our $our_len;
$our_len =3D length('abc');
is($our_len, 3, 'length("abc") with our variable must be 3');
$our_len =3D length(undef);
is($our_len, 0, 'length(undef) with our variable must be 0');
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
On Perl 5.10 (x64) I get:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
1..4
ok 1 - length("abc") with my variable must be 3
ok 2 - length(undef) with my variable must be 0
ok 3 - length("abc") with our variable must be 3
ok 4 - length(undef) with our variable must be 0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
On Perl 5.12 (x64), however, I get two test failures:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
1..4
ok 1 - length("abc") with my variable must be 3
not ok 2 - length(undef) with my variable must be 0
# Failed test 'length(undef) with my variable must be 0'
# at C:\testbug512.pl line 9.
# got: '3'
# expected: '0'
ok 3 - length("abc") with our variable must be 3
not ok 4 - length(undef) with our variable must be 0
# Failed test 'length(undef) with our variable must be 0'
# at C:\testbug512.pl line 17.
# got: undef
# expected: '0'
# Looks like you failed 2 tests of 4.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
------------------------------
Date: Fri, 20 Aug 2010 18:13:25 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl array bug?
Message-Id: <lmp2k7-lvc1.ln1@osiris.mauzo.dyndns.org>
Quoth Dilbert <dilbert1999@gmail.com>:
>
> This sounds very much like a regression in Perl 5.12.
>
> Here is an even simpler test case:
>
> ==============================
> use Test::More tests => 4;
>
> my $my_len;
>
> $my_len = length('abc');
> is($my_len, 3, 'length("abc") with my variable must be 3');
>
> $my_len = length(undef);
> is($my_len, 0, 'length(undef) with my variable must be 0');
length('abc') is constant-folded, so this can be reduced to
my $len = 3;
$len = length undef;
is($len, 0, "length(undef) == 0");
and now I can see where the problem is. 5.12 appears to have introduced
logic to make length(undef) be undef rather than 0, but it was done
incorrectly (specifically, the SETs macro isn't equivalent to the SETi
macro, in that it doesn't set TARG).
Malcolm: since I've now got both a clean testcase and a clear
understanding of the issue (and probably soon a patch), should I make
the bug report?
Ben
------------------------------
Date: Fri, 20 Aug 2010 17:54:16 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Perl array bug?
Message-Id: <i4mfg8a0qm002malch@news.sonic.net>
In article <lmp2k7-lvc1.ln1@osiris.mauzo.dyndns.org>, Ben Morrow <ben@morrow.me.uk> wrote:
>Malcolm: since I've now got both a clean testcase and a clear
>understanding of the issue (and probably soon a patch), should I make
>the bug report?
I did submit one here:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=77336
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Fri, 20 Aug 2010 09:07:26 -0700 (PDT)
From: Sal <here@softcom.net>
Subject: Perldoc: integers *stored* as... ???
Message-Id: <500354b5-1a83-4512-9b8d-1360fb306fee@q16g2000prf.googlegroups.com>
In the online Perl 5 version 12.1 documentation at:
http://perldoc.perl.org/perlnumber.html#Storing-numbers
Under the heading of Storing Numbers it reads "In fact numbers stored
in the native integer format may be stored either in the signed native
form, or in the unsigned native form."
Integers are *stored* as bits in a word, dword, or qword, it's how
they're interpreted that matters.
#!/usr/bin/perl
use strict;
use warnings;
my $x = 0xffff_ffff;
print $x, "\n";
printf("%d\n", $x);
On a 32-bit machine outputs:
4294967295
-1
------------------------------
Date: Fri, 20 Aug 2010 17:48:52 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perldoc: integers *stored* as... ???
Message-Id: <k8o2k7-dub1.ln1@osiris.mauzo.dyndns.org>
Quoth Sal <here@softcom.net>:
> In the online Perl 5 version 12.1 documentation at:
> http://perldoc.perl.org/perlnumber.html#Storing-numbers
>
> Under the heading of Storing Numbers it reads "In fact numbers stored
> in the native integer format may be stored either in the signed native
> form, or in the unsigned native form."
>
> Integers are *stored* as bits in a word, dword, or qword, it's how
> they're interpreted that matters.
Well, yes. Since 5.6.0, perl scalars have a flag bit in them that
indicates whether the stored number should be treated as signed or
unsigned.
> #!/usr/bin/perl
> use strict;
> use warnings;
> my $x = 0xffff_ffff;
> print $x, "\n";
> printf("%d\n", $x);
>
> On a 32-bit machine outputs:
> 4294967295
> -1
%d on a 32bit machine is inadequate for displaying Perl integers, since
it casts them to signed. This is perhaps a bug.
Note that on a perl with 32bit integers (that is, on a 32bit machine and
not built with use64bitint)
my ($x, $y) = (0xffff_ffff, -1);
print "$_\n" for $x, $y;
prints
4294967295
-1
despite the fact that the 32bit word actually storing the number has the
same value in both cases.
Ben
------------------------------
Date: Fri, 20 Aug 2010 11:31:35 -0400
From: Ralph Malph <ralph@happydays.com>
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
Message-Id: <91fe8$4c6e9fd7$40779ac3$13216@news.eurofeeds.com>
[asperger's fueled screed snipped]
tl, dnr
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3088
***************************************
