Re: perl pad.c Assertion !((sv)-sv_flags 0x00010000) failed
On Thu, 21 Jun 2007 22:33:03 +0100, Tim Bunce wrote:
On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
On 21/06/07, Steve Hay [EMAIL PROTECTED] wrote:
I remember lots of discussion a while ago about constructions like my
$x = 1 if $y;. I don't remember what the conclusion of it all was,
except that it's probably best avoided. Is that right?
Yes, that's right, because that could bypass initialisation of $x if
$y is false, leaving the previous value in it, like in state vars.
I thought that issue only related to a compile-time constant false
(such as the one in your example) and not to a runtime expression that
happened to be false sometimes.
Looking at it another way, are you saying that (ignoring closures)
subroutine scoped lexicals are not cleared when the subroutine exits,
but persist (consuming memory) until the subroutine is reentered?
$ ./perl -wle '$q = shift; sub foo { my $x if $q; print $x // $]; \
$x = 42 } foo; $q++; foo' 0
5.009005
42
It looks like it, no?
--
Peter Scott
Re: perl pad.c Assertion !((sv)-sv_flags 0x00010000) failed
On 6/22/07, Peter Scott [EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007 22:33:03 +0100, Tim Bunce wrote:
On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
On 21/06/07, Steve Hay [EMAIL PROTECTED] wrote:
I remember lots of discussion a while ago about constructions like my
$x = 1 if $y;. I don't remember what the conclusion of it all was,
except that it's probably best avoided. Is that right?
Yes, that's right, because that could bypass initialisation of $x if
$y is false, leaving the previous value in it, like in state vars.
I thought that issue only related to a compile-time constant false
(such as the one in your example) and not to a runtime expression that
happened to be false sometimes.
Looking at it another way, are you saying that (ignoring closures)
subroutine scoped lexicals are not cleared when the subroutine exits,
but persist (consuming memory) until the subroutine is reentered?
$ ./perl -wle '$q = shift; sub foo { my $x if $q; print $x // $]; \
$x = 42 } foo; $q++; foo' 0
5.009005
42
It looks like it, no?
I didnt want to say anything right away in the hope that Dave Mitchell
would answer it, and in the knowledge i might have something wrong,
but I seem to recall Dave explaining once in the past that perl trys
to optimise allocation of memory so that it doesnt have to reallocate
buffers every time a sub is entered. So basically storage for SV's is
preserved between invocations when possible. But i dont remember the
details and I just might be totally ass-backwards wrong.
cheers
Yves
--
perl -Mre=debug -e /just|another|perl|hacker/
RE: perl pad.c Assertion !((sv)-sv_flags 0x00010000) failed
From: Peter Scott [mailto:[EMAIL PROTECTED]
Sent: 22 June 2007 13:25
To: [EMAIL PROTECTED]; dbi-users@perl.org
Subject: Re: perl pad.c Assertion !((sv)-sv_flags 0x0001) failed
On Thu, 21 Jun 2007 22:33:03 +0100, Tim Bunce wrote:
On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
On 21/06/07, Steve Hay [EMAIL PROTECTED] wrote:
I remember lots of discussion a while ago about constructions like
my
$x = 1 if $y;. I don't remember what the conclusion of it all was,
except that it's probably best avoided. Is that right?
Yes, that's right, because that could bypass initialisation of $x if
$y is false, leaving the previous value in it, like in state vars.
I thought that issue only related to a compile-time constant false
(such as the one in your example) and not to a runtime expression
that
happened to be false sometimes.
Looking at it another way, are you saying that (ignoring closures)
subroutine scoped lexicals are not cleared when the subroutine exits,
but persist (consuming memory) until the subroutine is reentered?
$ ./perl -wle '$q = shift; sub foo { my $x if $q; print $x // $]; \
$x = 42 } foo; $q++; foo' 0
5.009005
42
It looks like it, no?
--
Peter Scott
To be fair most of the programming languages I'm familiar with don't
guarantee the value of a variable before its first assignment so I guess
this is to be expected.
The value will likely not be held over between calls but the value will
be unpredictable on each invocation.
Ken.
This e-mail and any accompanying documents contain confidential information
intended for a specific individual which is private and protected by law.
If you are not the intended recipient, any disclosure, copying, distribution or
other use of this information is strictly prohibited.
You are also requested to advise us immediately if you receive information
which is not addressed to you.
beCogent is Authorised and Regulated by the Financial Services
Authority.beCogent Registered Office Address:
75 Aldwych
London
WC2B 4JF
Company Registration Number: 3742876
Place of Registration: London
*
