localising hash element by variable

It seems inconceivable to me that so simple an example could
be a bug
in perl, and yet I cannot square the behaviour with my
expectations.
What am I missing?

The testcase that follows fails at least on 5.8.8 and
blead31281:

#!/usr/bin/perl -w
use strict;
my %v = (2 => 3);
my $el;
{ 
    $el = 2;
    local $v{$el} = 4;
    $el = 17;
}
use Data:umper;
print Dumper(%v);
if ($v == 3 && !$v) {
    # This is what I expected.
    print "okn";
} elsif ($v == 4 && $v == 3) {
    # This is what I see.
    print "not okn";
} else {
    # Hmm, you got yet another result.
    die "# whoa, freakyn";
}
__END__


If I am missing something stupid, my apologies: the source
of the test case
arose as a variation from my usual coding style, so I can
believe I might
not have come across this behaviour before. However I cannot
see anything
in perlsub 'Temporary Values via local()' to determine it
either way, which
should at least be remedied.

Hugo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Saturday 26 May 2007 13:34:17 hvcrypt.org wrote:
> It seems inconceivable to me that so simple an example
could be a bug
> in perl, and yet I cannot square the behaviour with my
expectations.
> What am I missing?
>
> The testcase that follows fails at least on 5.8.8 and
blead31281:
>
> #!/usr/bin/perl -w
> use strict;
> my %v = (2 => 3);
> my $el;
> {
>     $el = 2;
>     local $v{$el} = 4;
>     $el = 17;
> }
> use Data:umper;
print Dumper(%v);
> if ($v == 3 && !$v) {
>     # This is what I expected.
>     print "okn";
> } elsif ($v == 4 && $v == 3) {
>     # This is what I see.
>     print "not okn";
> } else {
>     # Hmm, you got yet another result.
>     die "# whoa, freakyn";
> }
> __END__

Hm, interesting it seems that you "save" $v
(==3), and "restore" $v 
to 3 afterwards. Clever.

All the best,

Tels

- - -- 
 Signed on Sun May 27 09:49:16 2007 with key 0x93B84C15.
 Get one of my photo posters: http://bloodgate.com/pos
ters
 PGP key on http://bloodgate.com/te
ls.asc or per email.

 Like my code? Want to hire me to write some code for you?
Send email!

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRllUfHcLPEOTuEwVAQJ/kgf+MTySkla9pV65DkFVENrcGJmKdema
xGal
NRGeIPoVRKZzaGbHccgQGQSAW5HW/fJh7kRticFYxyPYUC4phzOdFbyaNx2a
L7+j
u/YZ0GyWRZbobyGqH//0cXFyrKhFs4rKKEFKseLWoZQUBlPSnO2+Am4Y2XWm
iX/9
v40ogWxzuC3utmE8Fg6Lh/UVK4tGVnGhB1JoPXh3Ab2/cs4XJptt4XWqBru0
kIEp
ra6Vvnq/lD89No5JhAInn46klgA7ccmZytephvi78yPygqxOzJea8UEDqRXF
xb/M
EOuZbeEshStomw0+gwrufEOW59nufPA374L+rWb2DIbQJsmRQMcaqA==
=e7zH
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRllU0ncLPEOTuEwVAQJ1ugf+KrUPCYMCT3Fzut4owHgFaLqHy8nG
Zt/N
7Xcy4H1xW7ZNrdodrWSTT0tPGVcQKsVF01MQj/b5jQY8bRo94y64GEO10xkp
IEUC
eCXjTNQ8klSVMpujhoRJfhi0nj+l61hsb3rl993DYjW779wjS8G2n+7RTJuf
2svb
fGfQBfdoUaz4H5Ni1PFX8YOFIOWlmedxt/mWORFyr8dK06YsmlSyiQogt3zu
kQuQ
v1KFr/mcgTe/2xg7uyXUsY1d068kVoELRHmQUx+V4Q5HMrkFiwXYeLsY1yDk
H5SG
HNP5wOyN8Ar1BNAkwKAtgDkB0+Cnx99ezBJFJXXd9A8XwpVWNo6HBA==
=UZEh
-----END PGP SIGNATURE-----

On 5/26/07, hvcrypt.org <hvcrypt.org> wrote:
> It seems inconceivable to me that so simple an example
could be a bug
> in perl, and yet I cannot square the behaviour with my
expectations.
> What am I missing?
>
> The testcase that follows fails at least on 5.8.8 and
blead31281:
>
> #!/usr/bin/perl -w
> use strict;
> my %v = (2 => 3);
> my $el;
> {
>     $el = 2;
>     local $v{$el} = 4;
>     $el = 17;
> }
> use Data:umper;
print Dumper(%v);
> if ($v == 3 && !$v) {
>     # This is what I expected.
>     print "okn";
> } elsif ($v == 4 && $v == 3) {
>     # This is what I see.
>     print "not okn";
> } else {
>     # Hmm, you got yet another result.
>     die "# whoa, freakyn";
> }
> __END__
>
>
> If I am missing something stupid, my apologies: the
source of the test case
> arose as a variation from my usual coding style, so I
can believe I might
> not have come across this behaviour before. However I
cannot see anything
> in perlsub 'Temporary Values via local()' to determine
it either way, which
> should at least be remedied.

Personally I cant see how this could be anything but a bug.

yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

>>>>> On Sat, 26 May 2007 14:34:17 +0100,
hvcrypt.org said:

  > The testcase that follows fails at least on 5.8.8 and
blead31281:

What an awesome test. 9 years after the bug has been
introduced.

Broken by patch 768. Unfortunately a megapatch:

    Change 768 by mbeattielocalhost on 1998/03/05
18:13:06
    Integrate win32 branch into mainline.

-- 
andreas

A more minimal one, for reference:

%v = (2 => 3);
{
    $el = 2;
    local $v{$el} = 4; # bug
    #local $v = 4; # no bug
    $el = 17;
}

27 maj 2007 kl. 12.47 skrev (Andreas J. Koenig):
>>>>>> On Sat, 26 May 2007 14:34:17 +0100,
hvcrypt.org said:
>
>> The testcase that follows fails at least on 5.8.8
and blead31281:
>
> What an awesome test. 9 years after the bug has been
introduced.
>
> Broken by patch 768. Unfortunately a megapatch:
>
>     Change 768 by mbeattielocalhost on 1998/03/05
18:13:06
>     Integrate win32 branch into mainline.

Perl_save_helem in scope.c looks like the culprit to me.


/Bo Lindbergh

On 27/05/07, Bo Lindbergh <blglhagernas.com> wrote:
> Perl_save_helem in scope.c looks like the culprit to
me.

Your patch looks correct. Could you provide a patch to a
test file as well?

28 maj 2007 kl. 11.51 skrev Rafael Garcia-Suarez:
> On 27/05/07, Bo Lindbergh <blglhagernas.com> wrote:
>> Perl_save_helem in scope.c looks like the culprit
to me.
>
> Your patch looks correct. Could you provide a patch to
a test file  
> as well?

Can do.  t/op/local.t seems to be the logical choice.


/Bo Lindbergh

On 28/05/07, Bo Lindbergh <blglhagernas.com> wrote:
> 28 maj 2007 kl. 11.51 skrev Rafael Garcia-Suarez:
> > On 27/05/07, Bo Lindbergh <blglhagernas.com> wrote:
> >> Perl_save_helem in scope.c looks like the
culprit to me.
> >
> > Your patch looks correct. Could you provide a
patch to a test file
> > as well?
>
> Can do.  t/op/local.t seems to be the logical choice.

Thanks, applied as #31301.