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

[perl #43207] lc() or uc() inside sort affect the return value.

Thread Previous
From:
Father Chrysostomos via RT
Date:
January 4, 2014 13:38
Subject:
[perl #43207] lc() or uc() inside sort affect the return value.
Message ID:
rt-4.0.18-14623-1388842701-1832.43207-15-0@perl.org
On Sun Jul 29 11:04:32 2012, sprout wrote:
> On Thu Jun 14 04:26:54 2007, rafael wrote:
> > On 13/06/07, Rafael Garcia-Suarez <rgarciasuarez@gmail.com> wrote:
> > > On 13/06/07, Adriano Ferreira <a.r.ferreira@gmail.com> wrote:
> > > > Nope. The issue was lc() changing its argument. The example with sort
> > > > was only a way to demonstrate it.
> > > >
> > > > Here's another:
> > > >
> > > > $ perl -e ' $a = "Hello"; for ("$a") { lc $_; print }'
> > > > hello
> > >
> > > Yes, it seems that the logic in pp_lc is flawed:
> > >
> > >     if (SvPADTMP(source) && !SvREADONLY(source) && !SvAMAGIC(source)
> > >         && !DO_UTF8(source)) {
> > >         /* We can convert in place.  */
> > >         dest = source;
> > >
> > > Maybe we should add an SvTEMP check here too...
> > 
> > Now added (and to uc/lcfirst/ucfirst too) as change #31377.
> 
> (aka 17fa077605)
> 
> But PADTMPs are never SvTEMP, so now this optimisation never happens.  I
> tried adding assert(0), and all tests passed.
> 
> This bug is actually related to #78194.  If we make for() and ()x...
> (and other operations) copy the PADTMP ahead of time, preventing it ever
> from appearing on the stack twice, this bug would be fixed as a result,
> and 17fa077605 could be reverted.

I have re├źnabled in-place uc/lc in commit 5cd5e2d630.

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: resolved
https://rt.perl.org/Ticket/Display.html?id=43207

Thread Previous


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