develooper Front page | perl.perl5.porters | Postings from February 2018

Re: [perl #132595] multiconcat reading and fetching wrong order

Thread Previous
Leon Timmermans
February 20, 2018 10:08
Re: [perl #132595] multiconcat reading and fetching wrong order
Message ID:
On Tue, Feb 20, 2018 at 10:21 AM, Dave Mitchell <> wrote:
> Now fixed with:
> commit af39014264c90cfc5a35e4f6e39ba038a8fb0c29
> Author:     David Mitchell <>
> AuthorDate: Sat Feb 10 15:27:59 2018 +0000
> Commit:     David Mitchell <>
> CommitDate: Mon Feb 19 22:06:49 2018 +0000
>     redo magic/overload handing in pp_multiconcat
>     The way pp_multiconcat handles things like tieing and overloading
>     doesn't work very well at the moment. There's a lot of code to handle
>     edge cases, and there are still open bugs.
>     The basic algorithm in pp_multiconcat is to first stringify (i.e. call
>     SvPV() on) *all* args, then use the obtained values to calculate the total
>     length and utf8ness required, then do a single SvGROW and copy all the
>     bytes from all the args.
>     This ordering is wrong when variables with visible side effects, such as
>     tie/overload, are encountered. The current approach is to stringify args
>     up until such an arg is encountered, concat all args up until that one
>     together via the normal fast route, then jump to a special block of code
>     which concats any remaining args one by one the "hard" way, handling
>     overload etc.
>     This is problematic because we sometimes need to go back in time. For
>     example in ($undef . $overloaded), we're supposed to call
>         $overloaded->concat($undef, reverse=1)
>     so to speak, but by the time of the method call, we've already tried to
>     stringify $undef and emitted a spurious 'uninit var' warning.
>     The new approach taken in this commit is to:
>     1) Bail out of the stringify loop under a greater range of problematical
>     variable classes - namely we stop when encountering *anything* which
>     might cause external effects, so in addition to tied and overloaded vars,
>     we now stop for any sort of get magic, or any undefined value where
>     warnings are in scope.
>     2) If we bail out, we throw away any stringification results so far,
>     and concatenate *all* args the slow way, even ones we're already
>     stringified. This solves the "going back in time" problem mentioned above.
>     It's safe because the only vars that get processed twice are ones for which
>     the first stringification could have no side effects.
>     The slow concat loop now uses S_do_concat(), which is a new static inline
>     function which implements the main body of pp_concat() - so they share
>     identical code.
>     An intentional side-effect of this commit is to fix three tickets:
>         RT #132783
>         RT #132827
>         RT #132595
>     so tests for them are included in this commit.

Good stuff :-)


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About