return of hash-assigment in list context (bug?)

[LanX]

Honorable monks!

(EDIT: for a simplified bug-demo see update further down and one-liner post)

For Re: Syntax explanation required I tried to show the elimination of duplicates when assigning a list of two hashes to a third hash.

But while the third hash holds the correct results (line 105) the return value (line 102) of the assignment looks very weird, and I can't really explain whats happening.

  DB<100> %h1=(a=>1,b=>2);
 => ("a", 1, "b", 2)
 
  DB<101> %h2=(a=>11,c=>3);
 => ("a", 11, "c", 3)
 
  DB<102> %h=(%h1,%h2)
 => ("b", 2, "b", 2, "c", 3)
 
  DB<103> @ret = ( %h=(%h1,%h2) )
 => ("b", 2, "b", 2, "c", 3)
 
  DB<104> \@ret
 => ["b", 2, "b", 2, "c", 3]
 
  DB<105> %h
 => ("c", 3, "a", 11, "b", 2)

to be sure that it's not just my repl showing buggy results I reproduced it again on the console:

> perl
%h1=(a=>1,b=>2);
%h2=(a=>11,c=>3);
print (%h3=(%h1,%h2),"\n");
 
print %h3;
 
__END__
b2b2c3
c3a11b2

I'm still suffering from a little hangover from recent tumultuous events ... ;-)

So please could someone tell me what I am missing here?

UPDATE:

I was able to further isolate whats happening to a simple list assignment:

  DB<107> %h=("a", 1, "b", 2, "c", 3, "a", 11)
 => ("b", 2, "b", 2, "c", 3)
 
  DB<108> %h=("a", 1, "b", 2, "c", 3, "d", 4)
 => ("a", 1, "b", 2, "c", 3, "d", 4)
 
  DB<110> %h=("a", 1, "a", 11, "b", 2)
 => ("a", 11, "a", 11)

seems like that the fact that duplicated keys are eliminated (here a) somehow confuses the returned value.

[dsheroh]

What version of perl are you using? With my

This is perl 5, version 14, subversion 2 (v5.14.2) built for i686-linu
+x-gnu-thread-multi-64int

I get the results that I would expect, with no duplicated values:

$ perl
%h1=(a=>1,b=>2);
%h2=(a=>11,c=>3);
print (%h3=(%h1,%h2),"\n");
 
print %h3, "\n";
a11b2c3
c3a11b2

[LanX]

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

Thanks a lot... so it's an already fixed bug and I can stop chasing my faults! :)

[tobyink]

It appears to have been fixed between 5.12 and 5.14, though nothing is noted in perl5140delta.

[perl514]

Hi

Kindly let me know which OS you are using

[choroba]

I cannot replicate the bug in 5.14.2 nor 5.17.6. What version are you using?

[Anonymous Monk]

I can replicate it with 5.12.4 and 5.10.1, so I'm guessing it got fixed before 5.14

[Anonymous Monk]

Happens with 5.8.9 and 5.12.2

With the help of perldeltas and the keywords: return, pushmark , padhv, bind, assign, pad, ex-list, rv2hv, rv2av

Maybe this fixed it perl5140delta#given return values / http://search.cpan.org/dist/perl-5.14.0/pod/perlsyn.pod#Return_value

Maybe related #77498: Assignment ignores magick when the RHS holds a glob

not Maybe related perl5138delta#sv_compile_2op() is now deprecated

I say maybe, cause I didn't check the source to see if it was involved, or I couldn't track down what changed

update: aha , if checking perldeltas doesn't yield results, free probably will :) http://perl5.git.perl.org/perl.git?a=search&h=HEAD&st=free&s=aassign

Better fix for RT #2140 (list assignment with duplicated temporaries)

#2140: assigning array slice of function call to hash slice

That looks to be it, but you wouldn't know it from the bug report

[Anonymous Monk]

http://perl5.git.perl.org/perl.git?a=search&h=HEAD&st=free&s=hash+assign

2012-12-18
Dave RolskyBetter description of hash assignment bug fixes
Better description of hash assignment bug fixes

commit | commitdiff | tree


2012-12-18
Dave RolskyClarify hash assignment bug fix in list context
Clarify hash assignment bug fix in list context

commit | commitdiff | tree


2012-12-11
Father Chrysostomos[Merge] hash assignment fixes and speedup
[Merge] hash assignment fixes and speedup
 ...to left algorithm for not magic hash assignment
>     * in list context hash assignment return keys aliased to RHS

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovrefactor aassign
for array and hash assignment "while (relem <= SP)" loop

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovhash assign in list context should copy key as well
hash assign in list context should copy key... 

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovmake sure hash assignment is proper lvalue
make sure hash assignment is proper lvalue

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovfix issues in hash assignment with odd elements
fix issues in hash assignment with odd elements
3) hash assignment with duplicates and odd elements on

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovtest hash assignment with odd elements for leaks
test hash assignment with odd elements for leaks
 ...is tied and dies on fetch then hash assignment

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovtest "Odd number of elements in hash assignment"
test "Odd number of elements in hash assignment"

commit | commitdiff | tree


2012-09-23
Father ChrysostomosStop hash assignment from leaking on croak
Stop hash assignment from leaking on croak

commit | commitdiff | tree


2012-05-22
Lukas Maidocument behavior of duplicate keys in hash assignment
 ...behavior of duplicate keys in hash assignment

commit | commitdiff | tree


2010-09-11
David Mitchelllist cxt hash assign with dups gives garbage
list cxt hash assign with dups gives garbage

commit | commitdiff | tree

[LanX]

Thx, this one looks good! =)

2010-09-11 David Mitchell
list cxt hash assign with dups gives garbage

the others are too new.

Fix for #31865: weird results from reverse( %x = reverse %h )

Basically, anything of the form

@a = %h = (list with some duplicate keys)

may have left @a containing weird and/or freed values.

There was a partial fix for this with ca65944e, but it was broken (it did one big block move on the stack at the end to remove duplicates, but duplicates weren't necessarily all in one block.)

The new fix is a two-stage process. First, while pulling key/value pairs of the stack and assigning them to the hash, each key/val pair is written back to the stack - possibly at a lower position if there are duplicates to be skipped.

Finally at the end if any duplicates have been detected, then in list context, a single pass is made through the stack, and for each key/val pair, the key is looked up and the val on the stack is overwritten with the new value (replacing possibly freed or other garbage values).

[karlgoethebier]

"I'm still suffering from a little hangover from recent tumultuous events ..."

Hold on. Lent is coming soon. Perhaps the abbot can recommend some exercises for you?

Best regards, Karl