Re: [perl #37999] [RESOLVED] lc() + Latin-1 chars is failing erratically

I've confirmed that the bug no longer occurs when using chop(), or even 
s/\n// in the same place.

However, if we don't modify the string (no chomp/chop/etc.), remove the
"eq" check, and lc() it with newline and all, the accented U again stays
as-is. (This is with source from perl-current.)

I'm not familiar with Perl's internals, but if lc() is failing due to its
argument not having been previously mirrored in a Perl-internal UTF-8
representation... would it not make sense to have the check-and-reencode
bit at the top of lc()'s implementation (and in other functions making use
of encoding-dependent semantics), rather than attempt to cover all possible
origins of lc()'s argument?

And a quick question: As a workaround for my scripts, is there a concise
way of bestowing internal-UTF8-ness on a string without otherwise modifying
it?

• Re: [perl #37999] [RESOLVED] lc() + Latin-1 chars is failing erratically by Daniel Richard G.
• Re: [perl #37999] [RESOLVED] lc() + Latin-1 chars is failing erratically by Rafael Garcia-Suarez