develooper Front page | perl.perl5.porters | Postings from November 2014

new lex_assign.t failures (Re: [perl.git] branch blead,updated. v5.21.5-359-gf9e9590)

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
November 12, 2014 13:42
Subject:
new lex_assign.t failures (Re: [perl.git] branch blead,updated. v5.21.5-359-gf9e9590)
Message ID:
54636395.5070706@mac.com
On 11/10/14, 7:48 PM, Father Chrysostomos wrote:
> In perl.git, the branch blead has been updated
>
> <http://perl5.git.perl.org/perl.git/commitdiff/f9e95907d516e72aa3d1664d0723718e812957e6?hp=056c263b7eda0e9f899103c5f2bbef70ff44e9b8>
>
> - Log -----------------------------------------------------------------
> commit f9e95907d516e72aa3d1664d0723718e812957e6
> Author: Father Chrysostomos <sprout@cpan.org>
> Date:   Mon Nov 10 14:51:01 2014 -0800
>
>      Call STORE on lexical $tied = vec/chr
>
>      The assignment gets optimised away, so pp_vec and pp_chr need to call
>      SvSETMAGIC on their targets.
>
>      This bug started happening with vec just recently, in db098081, when
>      the OPpTARGET_MY optimisation was applied to it.
>
>      The bug started happening with chr for the same reason, but back in
>      5.6.0 (b162f9ea).
>
>      I moved the STORE tests down in lex_assign.t when expanding them, to
>      avoid sabotaging the tests that check the results of the expressions
>      after the __END__ marker.
>
> M	pp.c
> M	t/op/lex_assign.t


> @@ -248,6 +251,7 @@ rindex $posstr, 2		# rindex
>   sprintf "%i%i", $n, $n		# sprintf
>   ord $n				# ord
>   chr $n				# chr
> +chr ${\256}			# chr $wide
>   crypt $n, $n			# crypt

This change causes the following new test failures on VMS:

ok 76 - chr $wide
not ok 77 - crypt
# Failed test 77 - crypt at (eval 74) line 6
#      got "A\x{ad}\x{b6}9E\021\x{ec}\024"
# expected "A\000\0009E\021\000\024"
ok 78 - ucfirst padtmp

...

ok 224 - STORE count for substr
not ok 225 - STORE count for vec
# Failed test 225 - STORE count for vec at op/lex_assign.t;-0 line 135
#      got '0'
# expected /(?^:^1\z)/
ok 226 - STORE count for index
ok 227 - STORE count for rindex
ok 228 - STORE count for sprintf
ok 229 - STORE count for ord
not ok 230 - STORE count for chr
# Failed test 230 - STORE count for chr at op/lex_assign.t;-0 line 135
#      got '0'
# expected /(?^:^1\z)/
not ok 231 - STORE count for chr $wide
# Failed test 231 - STORE count for chr $wide at op/lex_assign.t;-0 line 135
#      got '0'
# expected /(?^:^1\z)/
ok 232 - STORE count for crypt
ok 233 - STORE count for ucfirst padtmp

The crypt test can be made to succeed by moving it before the
chr ${\256} test. But I don't understand why the order should matter or
what a "STORE count" is -- any advice on how to debug this?

In case it's relevant, I can say with some confidence that the crypt
function on VMS will not handle non-ASCII characters.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About