Re: Erm? Bug or not? Weird behaviour in hash / list conversion

The only difference I can see is entirely due to the map. Exclude that, and the rest is identical.

Well, yeah, but the map makes that you get four new 1's.

    print map 1, 1, 1, undef, 1;
[download]

will print out "1111".

So, a bug? If it is, it's been arounf since at least 5.6.1!

I think it's a bug. I think it will be hard to fix. And it has been around since at least 5.005.

Abigail

Comment on Re: Erm? Bug or not? Weird behaviour in hash / list conversion Download Code

Replies are listed 'Best First'.
Re: Re: Erm? Bug or not? Weird behaviour in hash / list conversion by Anonymous Monk on Oct 29, 2003 at 13:45 UTC
`pp_aassign: tmpstr = NEWSV(29,0); if (relem) sv_setsv(tmpstr,relem); (relem++) = tmpstr; didstore = hv_store_ent(hash,sv,tmpstr,0);` [download] Create new SV, copy stack SV into new SV, set stack element to new SV, store new SV in hash. hv_store_ent takes ownership of tmpstr; the second time key SV gets set, the first tempstr is dereffed while still on the stack. I don't immediately see why (relem++) has to be set to tmpstr. Other interesting oneliners: `perl -le 'print join ".", %h = (1,2,1,3,1,4)' 1.4.1..1.4 perl -le 'print join ".", %h = (1,2,1,3,1,[])' 1.ARRAY(0x80fa8cc).1.ARRAY(0x80fa8cc).1.ARRAY(0x80fa8cc)` [download]	[reply] [d/l] [select]
Re: Re: Erm? Bug or not? Weird behaviour in hash / list conversion by sauoq (Abbot) on Oct 29, 2003 at 17:38 UTC
And it has been around since at least 5.005. 5.004_04 (at least.) -sauoq "My two cents aren't worth a dime.";	[reply]