Bah. No, that's an editing mistake.
-zefram
> +++ b/t/re/substr.t
> @@ -682,4 +682,19 @@ is($x, "\x{100}\x{200}\xFFb");
> is(substr($a,1,1), 'b');
> }
>
> +# [perl #62646] offsets exceeding 32 bits on 64-bit system
> +SKIP: {
> + skip("32-bit system", 4) unless ~0 > 0xffffffff;
> + my $a = "abc";
> + my $r;
> + $w = 0;
> + $r = substr($a, 0xffffffff, 1);
> + is($r, undef);
> + is($w, 1);
> + $w = 0;
> + $r = substr($a, 0xffffffff+1, 1);
> + is($r, undef);
> + is($w--, 1);
> +}
> +
> }
Any reason for $w-- right at the end, instead of just $w?
Nicholas Clark
> Attached patch should fix bug #62646.
>
The patch doesn't change mg.c. Does that mean it doesn't fix lvalue subtr?
Oh, missed that. And upon looking further, it seems that #62646 has
widened in scope to consider all other string ops, which I didn't look at.
Jesse, as a 5.12 blocker, are you concerned just with substr, or with
all string ops?
-zefram
Thanks, applied to bleadperl as
b6d1426f94a845fb8fece8b6ad0b7d9f35f2d62e. I won't mark this bug fixed,
since it doesn't apply to lvalue substr, and since probably other
string functions have the limitation; however we may consider taking
it off the 5.12-blockers list.
I feel that the lvalue substr bug should remain on the blockers list, for now.
Nicholas Clark