In perl.git, the branch smoke-me/DosGlob has been created

<http://perl5.git.perl.org/perl.git/commitdiff/b4fbebdebb0ca08b0fd5e052deb2d8c7d60d527a?hp=0000000000000000000000000000000000000000>

        at  b4fbebdebb0ca08b0fd5e052deb2d8c7d60d527a (commit)

- Log -----------------------------------------------------------------
commit b4fbebdebb0ca08b0fd5e052deb2d8c7d60d527a
Author: Steffen Mueller <smuel...@cpan.org>
Date:   Wed Dec 12 07:35:21 2012 +0100

    Data::Dumper is at 2.139

M       Porting/Maintainers.pl

commit c8c262e361f01533a0c0bcb721ff2e0345391554
Author: Steffen Mueller <smuel...@cpan.org>
Date:   Wed Dec 12 07:33:33 2012 +0100

    Bring Data::Dumper version and changelog up to date with CPAN release
    
    The 2.139 CPAN release just went out. It has the same code that is in
    blead now, but it has distribution fixes on top of blead that wouldn't
    make sense here. This bumps the version and imports the change log.

M       dist/Data-Dumper/Changes
M       dist/Data-Dumper/Dumper.pm

commit 3d24912184050c3b750afa33180de19735f6b960
Author: Karl Williamson <pub...@khwilliamson.com>
Date:   Tue Dec 11 16:51:59 2012 -0700

    perlvar.pod: Slight clarification, typo

M       pod/perlvar.pod

commit 4b1e7f06143ab88e9b000eed23ae71e75b7c24b8
Author: Daniel Dragan <bul...@hotmail.com>
Date:   Tue Dec 11 14:01:54 2012 -0500

    better POD for mg_get and SvGROW
    
    SvGROW unconditionally derefs SvANY to check SvLEN. A crash occurs if the
    sv is SVt_NULL. Also mg_get uses SvMAGIC which also has the same problem.
    Rather than having people finding these properties out by trial and error,
    document them. There is no sense in adding type checks since these 2 calls
    have been had sv type restrictions since probably day 1 and for
    performance reason. Anyone who hit the restrictions would have either
    fixed their code immediately, or abandoned using XS. I observed someone
    abandoning XS in the field over these undocumented restrictions.

M       mg.c
M       sv.h

commit d2192f4f82773968f8eb344c3b3b3836b271aa06
Author: Father Chrysostomos <spr...@cpan.org>
Date:   Tue Dec 11 16:18:40 2012 -0800

    Really fix t/op/lex.t
    
    I *thought* I had run the tests after making commit 6d70c68615.

M       t/op/lex.t

commit 23b7025ebc631174249ce95dd496a0f82b55701a
Merge: 6d70c68 1d2b392
Author: Father Chrysostomos <spr...@cpan.org>
Date:   Tue Dec 11 08:59:56 2012 -0800

    [Merge] hash assignment fixes and speedup
    
    In <CAMOxC8vCaYk3GD0NRH=jxgmnku+bmktrykr2nsrgu6wei+x...@mail.gmail.com>
    Ruslan Zakirov wrote:
    > I've finished my work on pp_aassign. I find it ready for review.
    > Each commit has plenty of details, but here is short description:
    >
    >     * scalar(%h = (1,1,1,1)) returns 4, not 2
    >     * warn on ($s,%h) = (1,{}) as on (%h) = ({})
    >     * (%h = (1)) in list context returns (1, $h{1})
    >       instead of (1)
    >     * return of (%h = (1,1,1)) in list context was incorrect
    >     * in list context returned keys was aliased to RHS scalars
    >       of aassign
    >     * returned list from ((%h, @a) = ...), hash on LHS followed by
    >       array or hash, was incorrect
    >     * implemented right to left algorithm for not magic hash assignment
    >       in scalar and void context
    >     * use less mortals is list context
    >     * in list context hash assignment return keys aliased to RHS
    >       when it's ok (it's not LVALUE context)

commit 1d2b3927543a3fa4089c1cee10f3a1a546a02cfe
Author: Hugo van der Sanden <h...@crypt.org>
Date:   Tue Dec 11 06:17:26 2012 -0800

    pp_hot.c: Comments to clarify pp_aassign
    
    [The committer took these from <201210240658.q9o6w1u25...@crypt.org>
    and turned them into a patch.]

M       pp_hot.c

commit 3d2de69e2d8b4ab2d3b4e978957fce16e6597548
Author: Father Chrysostomos <spr...@cpan.org>
Date:   Tue Dec 11 05:59:00 2012 -0800

    hashassign.t: Suppress oddball warnings

M       t/op/hashassign.t

commit 14da5e9ef04c8dab84c9c1e5818ec57fbae6fca0
Author: Father Chrysostomos <spr...@cpan.org>
Date:   Tue Dec 11 05:57:41 2012 -0800

    hashassign.t: Test undef explicitly
    
    thereby eliminating uninit warnings

M       t/op/hashassign.t

commit 631dbaa279974476f7c2a388b50c77dace949921
Author: Father Chrysostomos <spr...@cpan.org>
Date:   Wed Oct 24 18:04:20 2012 -0700

    Copy keys for aassign in lvalue sub
    
    Checking LVRET (which pp_aassign does, as of a few commits ago)
    has no effect if OPpMAYBE_LVSUB is not set on the op.  This com-
    mit changes op.c:op_lvalue_flags to set this flag on aassign ops.
    
    This makes sub:lvalue{%h=($x,$x)} behave correctly if the return
    values of the sub are assigned to ($x is unmodfied).

M       dump.c
M       op.c
M       t/op/hashassign.t

commit fb8f4cf83c7112774ede7101826d438234894195
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Sat Oct 20 14:40:13 2012 +0400

    hash argument is not used anymore in do_oddball
    
    rename arguments to make more clear what function takes

M       embed.fnc
M       embed.h
M       pp_hot.c
M       proto.h

commit 632b9d6f6a19a87ee168ebb81494b7df13c2eeb0
Author: Father Chrysostomos <spr...@cpan.org>
Date:   Mon Dec 10 05:43:41 2012 -0800

    pp_hot.c:pp_aassign: mortalise variable only if we have to
    
    This affects the hash-assignment path.
    
    Don’t mortalise the value to protect it from a magical key making the
    hv_store_ent call die, as that could unduly extend the mortals stack.
    
    Instead, copy the key if it is magical.
    
    Based on a patch by Ruslan Zakirov.

M       pp_hot.c

commit 88e2091baeacd9a40eab4dac8601e88b3797e385
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Wed Oct 17 20:04:58 2012 +0400

    don't create a copy of keys if it's not LVALUE context
    
    Making another copy slows things down. We can avoid it
    if aassign is not expected to return LVALUEs.

M       pp_hot.c

commit 1c4ea38437d309ec547e78e6f14940e799920be3
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Sun Oct 14 04:41:35 2012 +0400

    refactor aassign
    
    move populating stack with return values. Place it
    into main loop right after we stored values.
    
    This allow us to delete special if blocks for
    hash/array on LHS followed by other hash/array.
    
    Also, clearing HV out of ENTER/LEAVE block is bad -
    segfaults in corner cases.
    
    Don't use goto for odd elements case.
    
    store undef on stack for odd case. we can avoid NULL
    checks in the loop and use assert like array assignment
    does.
    
    use SvSETMAGIC rather than repeate what it means.
    
    for array and hash assignment "while (relem <= SP)" loop
    at the end was always empty. Put it into else branch.

M       pp_hot.c

commit 4ff6ceafd69f873d6db07cde3cb7c5cb6e8fef2d
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Sat Oct 13 21:28:10 2012 +0400

    ary/hash/firsthashelem should be set only once
    
    Only once for first hash or array, otherwise
    (%h,@a) = ... assignment returns wrong results
    for duplicates and/or number of elements on RHS.

M       pp_hot.c

commit a88bf2bcaa12203b1be20c254990b132faf927dd
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Sat Oct 13 21:27:12 2012 +0400

    we need duplicates counter only in list context

M       pp_hot.c

commit b1babc516d40c1a9d24a2eabf3c7649c4c3e7a00
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Wed Oct 10 02:43:40 2012 +0400

    test return values of aassign with various elements on LHS
    
    * hash on LHS followed by array, other hash or scalar,
      for example (%h, @a) = (...);
    
    * above with normal RHS, with duplicates, odd elements
      and combination.
    
    * inspect elements returned by aassign for lvaluedness
    
    * assign doesn't return elements that were just cleared

M       t/op/hashassign.t

commit 139e2abeba926fdfd45724ed2ab5117bfabdb350
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Mon Oct 8 22:50:50 2012 +0400

    hash assign in list context should copy key as well
    
    if we don't then returned keys are aliases for RHS
    values and can result in unexpected changes

M       pp_hot.c

commit 96e574609cc4b7f8d8969f8da065712307311f41
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Mon Oct 8 22:48:52 2012 +0400

    make sure hash assignment is proper lvalue

M       t/op/hashassign.t

commit 1baa394bebe0d74f5a4f14772cc9000d6bdc99f7
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Mon Oct 8 17:32:24 2012 +0400

    fix issues in hash assignment with odd elements
    
    1) unify code path of processing odd case with regular
    loop that process pairs. fixes memory leak when key
    is magic and dies on fetch.
    
    2) in list context put undef that we added to compensate
    odd elements into returned values, so (%h = (1))
    returns (1, $h{1}) rather than (1). This is documented
    in perldoc perlop:
    
        a list assignment in list context produces the list
        of lvalues assigned to.
    
    Here can be a dispute, but:
    
    * that key without value on RHS is still assigned with
      undef
    * consider (%h = (1,2,3,4,5,6,3)). Returning (1,2,3,undef,5,6)
      is much easier than (1,2,5,6,3).
    * order of returned elements follows cases with even number
      of elements on RHS and duplicates
    
    3) hash assignment with duplicates and odd elements on
    RHS was returning wrong results in list context.
    Now (%h = (1,1,1)) returns (1,$h{1}).

M       pp_hot.c

commit 499ace3b7bbe6fb3aa489db1fb760ac0a6dbbd1b
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Mon Oct 8 17:26:43 2012 +0400

    test hash assignment with odd elements for leaks
    
    if key scalar is tied and dies on fetch then hash assignment
    is leaking a key value

M       t/op/svleak.t

commit be1092b8b2529803333f6d1be2025b9af797f010
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Mon Oct 8 02:41:06 2012 +0400

    warn on ($s,%h) = (1,{}) as on %h = {}
    
    Latter results in "Reference found where even-sized list expected"
    message while former produces "Reference found where even-sized list
    expected". Quite inconsistent.

M       pp_hot.c

commit 3e125adaaf6d41df6a78e92e6682685224048aba
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Mon Oct 8 02:35:22 2012 +0400

    test "Odd number of elements in hash assignment"

M       t/op/hashassign.t

commit 231cbeb24ba077cbde643fc4d5178055c1464f5c
Author: Ruslan Zakirov <r...@bestpractical.com>
Date:   Mon Oct 8 02:30:54 2012 +0400

    scalar(%h = (1,1,1,1)) should return 4, not 2
    
    perldoc perlop says:
    
        a list assignment in scalar context returns the number of elements
        produced by the expression on the right hand side of the assignment
    
    Behaviour was changed as side effect of
    ca65944e8ff8fff6e36ea7476ba807be16cfe2a9 where goal was to fix
    return value in list context.

M       ext/Hash-Util-FieldHash/t/11_hashassign.t
M       pp_hot.c
M       t/op/hashassign.t

commit 6d70c686156da1532212fbc817c63c0a02bf894a
Author: Father Chrysostomos <spr...@cpan.org>
Date:   Sun Dec 9 05:03:50 2012 -0800

    t/op/lex.t: Fix test
    
    It was a copied-and-pasted repeat of another test, both of which I
    added in commit 67a057d6d.  I know it used to crash and the commit
    fixed it, as I tested it at the time with one-liners.

M       t/op/lex.t
-----------------------------------------------------------------------

--
Perl5 Master Repository

Reply via email to