Front page | perl.perl5.porters |
Postings from August 2013
On Sun Jul 28 15:49:39 2013, sprout wrote:
> On Sat Jul 27 14:19:32 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de
wrote:
> > git bisect
> > ----------
> > 19130678b46bff1627099e92f818913a1bade9b0 is the first bad commit
> > commit 19130678b46bff1627099e92f818913a1bade9b0
> > Author: Father Chrysostomos <sprout@cpan.org>
> > Date: Tue Jul 2 19:53:05 2013 -0700
> >
> > Make overloaded constants always read-only
> >
> > diagnostics
> > -----------
> > Modification of a read-only value attempted at t/a.t line 43.
> > # Looks like you planned 30 tests but ran 3.
> > # Looks like your test exited with 255 just after 3.
> > t/a.t ......................
> > Dubious, test returned 255 (wstat 65280, 0xff00)
> > Failed 27/30 subtests
>
> I changed this back in commit ba36554e02, but only for shared hash key
> scalars. So such ‘constants’ are only mutable now in those cases where
> they have been historically. Constants derived from new copy-on-write
> scalars are still read-only.
>
> I think this ticket should stay open until we decide what is the best
> thing to do here.
>
By changing it back, I reintroduced a bug. I didn’t realise just how
buggy it was before:
$ ./perl -Ilib -e 'use overload; BEGIN { overload::constant integer =>
sub { __PACKAGE__ }; } for ("",""){for(5){ warn $_; $_++ }}'
main at -e line 1.
maio at -e line 1.
The SV stored in the op tree can be modified.
I see the same behaviour all the way back to 5.10. Maybe the best
solution here is to make it read-only, and just force the module to adapt.
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=119043
Thread Previous
|
Thread Next