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

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.

-- 

Father Chrysostomos


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

• [perl #43207] lc() or uc() inside sort affect the return value. by Father Chrysostomos via RT
• [perl #43207] lc() or uc() inside sort affect the return value. by Father Chrysostomos via RT